AX_CacheRecords [ADS]

Форум » Clipper » AX_CacheRecords [ADS] » Ответить

AX_CacheRecords [ADS]

Dima: [pre2] Есть у кого то опыт использования 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 [/pre2]

Ответов - 22, стр: 1 2 All

p519446: Извиняйте за некрофильство, но подниму-ка топик. В доке сказано: --- 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

p519446: Вот тут: 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" на бОльшее значение ?

Dima: размер пакета поменять можно а вот их кол-во что то не вижу зы не уверен но может это оно BLINKER EXECUTABLE IPX

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

Dima: p519446 пишет: 1) как это "размер пакета можно" ? ведь в IPX'e он жестко забит равным 512 ADS.INI для clipper он не катит [pre2] 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 [/pre2]

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

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

Dima: В Clipper после открытия базы я делал так [pre2] Открыл базу 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) [/pre2]

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

p519446: В общем, провел я предварительный тест скорости "вычитки" строк. Взял таблицу табличных частей расходов, выкинул из неё 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-полем. Результаты, скорее всего, будут "гораздо другие" (и гораздо отвратительнее в плане производительности).

Dima: p519446 пишет: Результат сложил в эксель, вот тынц: http://yadi.sk/d/N9qJbPkd5C9El (этот файлик размером 19 Кб лежит на яндекс.диске, так что храниться будет вечно). [pre2] Ой, что-то сломалось… Открыть документ не удалось. Пожалуйста, повторите попытку позже. [/pre2]

p519446: Dima пишет: Открыть документ не удалось. Пожалуйста, повторите попытку позже. гм... у мну открылось ОК еще с двух машин... ну, вот еще одна, уже на .rar-файл: http://yadi.sk/d/gwE9MhCo5CVGm

p519446: Закончил аналогичный эксперимент с этой же таблицей, но уже НЕ удалял в ней memo-поле. Средняя длина memo-поля в обмолоченных записях - хз какая, но по бОльшей части - от 30 до 50 байт. Результат-1. Число строк, обрабатываемых в 1 сек, в таблице *без* memo-поля, от 1.5 до 2.2 раза быстрее, чем в таблице *с* memo-полем - для случая, когда подавляющее бол-во строк в мемо имеет длину менее 100 байт. Результат-2. Наибольшее число строк в секунду обрабатывается при значении кешируемого числа записей ('n') от 5 до 50. При дальнейшем увеличении числа 'n' число обрабатываемых строк начинает МЕДЛЕННО падать. Но падение произв-сти не такое выраженное, как в варианте БЕЗ мемо-поля. Вот тут лежит СВОДНЫЙ результат по обоим тестам (*без* и *с* мемо-полями): http://yadi.sk/d/ZHw9aZqA5CWy2 Это эксельный файл с двумя листами. В первом листе - результаты *без* мемо, но также скопированы для удобства сравнивания результаты теста *с* мемо. Во втором листе - наоборот, слева указаны сведения по тесту *с* мемо, справа - добавлены данные из первого листа. "Желаю приятного просмотра" :-)

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

p519446: 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 ?

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

p519446: вот результат тестирования той же таблицы *с* мемо-полями и различными вариантами сборки .exe: bli exe ipx 32 | 48 | 64 | 72 | 100 http://ge.tt/4U0Hnlh/v/0 Никакой особой разницы не проявилось. Заметно, впрочем, что наилучшие показатели будут при ax_cacherecords() до 100 строк.

Dima: p519446 пишет: Заметно, впрочем, что наилучшие показатели будут при ax_cacherecords() до 100 строк это типа на глазок ? при такой установке и кол-ве записей в базе менее 100 прога у тебя упадет

p519446: 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)

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

полная версия страницы