On-line: Pasha, Haz, SergKis, гостей 2. Всего: 5 [подробнее..]
АвторСообщение
администратор




Пост N: 1835
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 27.07.10 15:16. Заголовок: AX_CacheRecords [ADS]


 
Есть у кого то опыт использования AX_CacheRecords() (ADS) ?
Не давно поигрался с этой функцией и ее параметром.
Удалось повысить скорость создания отчетов примерно в 4 раза.
Обычно в отчетах работает конструкция вида
do while !eof() // или что то другое
// тут что то делаем
skip
enddo

Мануал гласит:
/*
Максимальное количество записей, которые могут быть кэшированы у кли-
ента - количество, соответствующее 64 Кбайтам данных. Т.к. каждая за-
пись имеет 4 дополнительных (служебных) байта, то мы получим макси-
мальное количество записей:

nNumRecords = 65535 / ( размер записи + 4 )
*/

Долго подбирал оптимальный параметр в AX_CacheRecords()
CashRec:=int(nNumRecords/5.4)
И пришел вот к такому AX_CacheRecords(CashRec)

Какие будут соображения ?

PS
Протокол IPX/SPX





Спасибо: 0 
ПрофильЦитата Ответить
Ответов - 22 , стр: 1 2 All [только новые]





Пост N: 141
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 26.05.13 09:31. Заголовок: Извиняйте за некрофи..


Извиняйте за некрофильство, но подниму-ка топик.
В доке сказано:
---
The default number of records that is read and cached on the client is the
lesser of 10 or the number of records that can fit in a burst of packets from the
Advantage Database Server to the Advantage client.
The *default* burst of packets can contain 8K bytes of data.
---

Каким параметром в ads.cfg регулируется этот самый "burst of packets" ?

PS. ADS 7.0 for NetWare

Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 142
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 26.05.13 09:39. Заголовок: Вот тут: http://devz..


Вот тут: http://devzone.advantagedatabase.com/dz/webhelp/Advantage7.1/advantage/advantage_communication_transport_layer.htm - сказано, что
"A single IPX packet is limited to 512 bytes of data. <...> Advantage will send up to 16 packets at once in a single burst. Thus, a burst of IPX packets can contain up to 8K bytes of data"

Можно ли поменять эти самые "up to 16 packets at once" на бОльшее значение ?

Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3172
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 26.05.13 09:56. Заголовок: размер пакета поменя..


размер пакета поменять можно а вот их кол-во что то не вижу


зы
не уверен но может это оно BLINKER EXECUTABLE IPX

Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 143
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 26.05.13 10:07. Заголовок: 1) как это "разм..


1) как это "размер пакета можно" ? ведь в IPX'e он жестко забит равным 512
2) BLINKER EXECUTABLE IPX - но ведь это установка повлияет только на клиента, так ? сервак-то знать об этом не будет, КМК...


Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3173
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 26.05.13 10:09. Заголовок: p519446 пишет: 1) ..


p519446 пишет:

 цитата:

1) как это "размер пакета можно" ? ведь в IPX'e он жестко забит равным 512



ADS.INI для clipper он не катит
 
PACKET_SIZE

The PACKET_SIZE setting must exist within a section titled "[SETTINGS]". The default protocol packet size is determined by which protocol is
being used by the Advantage communication layer. For IPX packets, the default packet size is 576 bytes.
For IP, the default and maximum packet size is 1450 bytes. This setting may be used to further restrict the size of the network packet that is
used while communicating with the Advantage Database Server. For example, if a router is fragmenting packets artificially, this setting can
eliminate that problem by reducing the packet size. It is recommended to not use this setting unless needed.


[SETTINGS]

; This will change the packet size to 512 bytes. Adjusting this size is not recommended unless you are sure it will help performance.

PACKET_SIZE=512




Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 144
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 26.05.13 10:16. Заголовок: а, понятно. ладно, б..


а, понятно.
ладно, буду играться только с аргументом ax_cacherecords().

Я так понял, надо будет собрать по каждой таблице, интенсивно участвующей в отчетах, статистику по средней длине записи (с учетом содержимого memo, судя по всему). Ну, и среднее число строк в табличных частях для различных видов документов (приходов / расходов / ремонтных нарядов etc).

Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3174
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 26.05.13 10:19. Заголовок: p519446 пишет: Я та..


p519446 пишет:

 цитата:
Я так понял, надо будет собрать по каждой таблице, интенсивно участвующей в отчетах, статистику по средней длине записи (с учетом содержимого memo, судя по всему). Ну, и среднее число строк в табличных частях для различных видов документов (приходов / расходов / ремонтных нарядов etc).


Да

Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3175
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 26.05.13 10:21. Заголовок: В Clipper после откр..


В Clipper после открытия базы я делал так

 
Открыл базу
AX_CacheRecords(LenReCash())

***************
Func LenReCash()
local ret:=0
local i
FOR i = 1 TO fcount()
ret+=FIELDSIZE(i)
NEXT

ret+=4

return int((65535/ret)/5.4)



Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 145
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 26.05.13 10:27. Заголовок: кхе! тебе хорошо, у ..


кхе! тебе хорошо, у тебя memo-полей нету... ;-)
мну надо будет по-другому делать: обмолотить за последние год-два все записи, собрать статистику по длине с учетом мемо, а затем применить одну рекурсивную процедурку для выкидывания "нетипичных значений" (флуктуаций), чтобы получить достоверные значения среднего.

Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 146
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 26.05.13 21:47. Заголовок: В общем, провел я пр..


В общем, провел я предварительный тест скорости "вычитки" строк.
Взял таблицу табличных частей расходов, выкинул из неё memo-поле (для постоянства размера длины записи).
Число строк в ней = 3.6 млн, длина записи = 190 байт. Разумеется, есть индекс по doc_id. По нему и проводилась "вычитка" строк, как и делается во многих местах в программе.
Далее в случайном порядке брал в таблице заголовков расходов документ за последние ~3 года (глубже копают редко).
И затем выполнял в таблице детализации
dbSeek( randomly_selected_doc_id )
while !eof().and. doc_id = randomly_selected_doc_id
for i=1 to fcoun()
xval = fieldget( i ) // вычитка значений всех полей записи
end
skip
end

Значения аргумента `n` для ax_cacherecords( n ) выбирались от 5 до 335 с шагом = 5.
Для каждого из выбранных значений (т.е. для каждого числа из ряда: {5, 10, 15, ..., 335 } делалась выборка из 1000 документов.
Перед и после этой выборки засекалось значение seconds().

Эксперимент повторял 5 раз, начиная примерно с 20 ч мск, т.е. когда нагрузка на мой сервак от усеров была уже почти нулевой (а после 21 ч - точно нулевой).
Результат сложил в эксель, вот тынц: http://yadi.sk/d/N9qJbPkd5C9El (этот файлик размером 19 Кб лежит на яндекс.диске, так что храниться будет вечно).

Краткое резюме: на этом .dbf'нике скорость от увеличения аргумента при вызове ax_cacherecords() *ОТСУТСТВУЕТ*.
Более того: лучшая скорость проявляется при значении n=5, а вовсе не дефолтном 10!

Сейчас запустил уже для этого же файла, но с memo-полем. Результаты, скорее всего, будут "гораздо другие" (и гораздо отвратительнее в плане производительности).

Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3176
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 26.05.13 22:34. Заголовок: p519446 пишет: Резу..


p519446 пишет:

 цитата:
Результат сложил в эксель, вот тынц: http://yadi.sk/d/N9qJbPkd5C9El (этот файлик размером 19 Кб лежит на яндекс.диске, так что храниться будет вечно).


 
Ой, что-то сломалось…
Открыть документ не удалось. Пожалуйста, повторите попытку позже.


Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 147
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 00:28. Заголовок: Dima пишет: Открыть..


Dima пишет:
 цитата:
Открыть документ не удалось. Пожалуйста, повторите попытку позже.

гм... у мну открылось ОК еще с двух машин...
ну, вот еще одна, уже на .rar-файл:

http://yadi.sk/d/gwE9MhCo5CVGm

Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 148
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 01:17. Заголовок: Закончил аналогичный..


Закончил аналогичный эксперимент с этой же таблицей, но уже НЕ удалял в ней memo-поле.
Средняя длина memo-поля в обмолоченных записях - хз какая, но по бОльшей части - от 30 до 50 байт.

Результат-1. Число строк, обрабатываемых в 1 сек, в таблице *без* memo-поля, от 1.5 до 2.2 раза быстрее, чем в таблице *с* memo-полем - для случая, когда подавляющее бол-во строк в мемо имеет длину менее 100 байт.

Результат-2. Наибольшее число строк в секунду обрабатывается при значении кешируемого числа записей ('n') от 5 до 50. При дальнейшем увеличении числа 'n' число обрабатываемых строк начинает МЕДЛЕННО падать. Но падение произв-сти не такое выраженное, как в варианте БЕЗ мемо-поля.

Вот тут лежит СВОДНЫЙ результат по обоим тестам (*без* и *с* мемо-полями):

http://yadi.sk/d/ZHw9aZqA5CWy2

Это эксельный файл с двумя листами. В первом листе - результаты *без* мемо, но также скопированы для удобства сравнивания результаты теста *с* мемо.
Во втором листе - наоборот, слева указаны сведения по тесту *с* мемо, справа - добавлены данные из первого листа.

"Желаю приятного просмотра" :-)


Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 149
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 01:21. Заголовок: PS. на всякий случай..


PS. на всякий случай, дублирую еще и сюда: http://ge.tt/9PEBTjh/v/0

Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 150
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 12:52. Заголовок: Dima пишет: не увере..


Dima пишет:
 цитата:
не уверен но может это оно BLINKER EXECUTABLE IPX

Протестировал с bli exe ipx 48, запустил с 64.
Пока не вижу разницы.

По тексту доки:
" Each ECB buffer specified requires approximately 42 bytes of conventional memory, and each send buffer specified requires approximately 550 bytes. The total size of both types of buffers may not exceed 64Kb when added together. " - непонятно, на что следует делить 65536, чтобы получить макс. допустимое значение числа ECB: на 42 или на 550 или на 42+550 ?

Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3177
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 27.05.13 13:38. Заголовок: p519446 пишет: Прот..


p519446 пишет:

 цитата:
Протестировал с bli exe ipx 48, запустил с 64.
Пока не вижу разницы.


я тоже не увидел


Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 151
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 14:50. Заголовок: вот результат тестир..


вот результат тестирования той же таблицы *с* мемо-полями и различными вариантами сборки .exe:
bli exe ipx 32 | 48 | 64 | 72 | 100

http://ge.tt/4U0Hnlh/v/0

Никакой особой разницы не проявилось. Заметно, впрочем, что наилучшие показатели будут при ax_cacherecords() до 100 строк.

Спасибо: 0 
ПрофильЦитата Ответить
администратор




Пост N: 3178
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 27.05.13 17:11. Заголовок: p519446 пишет: Заме..


p519446 пишет:

 цитата:
Заметно, впрочем, что наилучшие показатели будут при ax_cacherecords() до 100 строк


это типа на глазок ?
при такой установке и кол-ве записей в базе менее 100 прога у тебя упадет

Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 152
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 21:01. Заголовок: Dima пишет: это типа..


Dima пишет:
 цитата:
это типа на глазок ?
при такой установке и кол-ве записей в базе менее 100 прога у тебя упадет

ну, вобщем-то да - "беглый визуальный осмотр".
Детально анализировать эти цифры в лом, да и смысла нет: не вижу ощутимой разницы между временнЫми результатами.
Что касается кол-ва записей менее 100, то это не грозит: нет у мну таких таблиц, да и не было никогда. А если бы и были, то добавить в формулу определения 'n' значение recCount() никогда не поздно.

Да, и еще.
Напоследок я решил сверить результат вычитки во индексу vs вычитки по natural'-порядку, предварительно устанавливая ax_setServerAOF('doc_id = "'+selected_doc_id+'"') // у этого фильтра opt_level =1, разумеется.
Так вот: странное дело, но обработка строк по индексу почему-то БЫСТРЕЕ при n <= 130, а затем сравнивается и далее становится медленнее.

Вот результат этого теста: http://folder.rusfolder.net/files/36586743 (файл 31 Кб, доступна до 2013-06-26 22:00:50)



Спасибо: 0 
ПрофильЦитата Ответить



Пост N: 153
Зарегистрирован: 07.08.06
ссылка на сообщение  Отправлено: 27.05.13 21:05. Заголовок: PS. Была еще идея пр..


PS. Была еще идея проверить (вместо 'n' в ax_cacherecords()) влияние установки в ads.cfg COMPRESSION = always и пересборки клиента с соотв-щей библой. Но хорошо, что глянул в свои же комменты в этом ads.cfg: оказывается ads.nlm может заваливаться при этом с какой-то ошибкой, связанной с его стеком. В общем, стрёмно это как бэ :-)


Спасибо: 0 
ПрофильЦитата Ответить
Ответов - 22 , стр: 1 2 All [только новые]
Ответ:
1 2 3 4 5 6 7 8 9
большой шрифт малый шрифт надстрочный подстрочный заголовок большой заголовок видео с youtube.com картинка из интернета картинка с компьютера ссылка файл с компьютера русская клавиатура транслитератор  цитата  кавычки моноширинный шрифт моноширинный шрифт горизонтальная линия отступ точка LI бегущая строка оффтопик свернутый текст

показывать это сообщение только модераторам
не делать ссылки активными
Имя, пароль:      зарегистрироваться    
Тему читают:
- участник сейчас на форуме
- участник вне форума
Все даты в формате GMT  3 час. Хитов сегодня: 637
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет