Автор | Сообщение |
|
| |
Пост 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
|
|
|
Ответов - 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
|
|
|
|
| |
Пост N: 142
Зарегистрирован: 07.08.06
|
|
Отправлено: 26.05.13 09:39. Заголовок: Вот тут: http://devz..
|
|
|
|
| |
Пост N: 3172
Зарегистрирован: 17.05.05
|
|
Отправлено: 26.05.13 09:56. Заголовок: размер пакета поменя..
размер пакета поменять можно а вот их кол-во что то не вижу зы не уверен но может это оно BLINKER EXECUTABLE IPX
|
|
|
|
| |
Пост N: 143
Зарегистрирован: 07.08.06
|
|
Отправлено: 26.05.13 10:07. Заголовок: 1) как это "разм..
1) как это "размер пакета можно" ? ведь в IPX'e он жестко забит равным 512 2) BLINKER EXECUTABLE IPX - но ведь это установка повлияет только на клиента, так ? сервак-то знать об этом не будет, КМК...
|
|
|
|
| |
Пост 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
|
|
|
|
| |
Пост N: 144
Зарегистрирован: 07.08.06
|
|
Отправлено: 26.05.13 10:16. Заголовок: а, понятно. ладно, б..
а, понятно. ладно, буду играться только с аргументом ax_cacherecords(). Я так понял, надо будет собрать по каждой таблице, интенсивно участвующей в отчетах, статистику по средней длине записи (с учетом содержимого memo, судя по всему). Ну, и среднее число строк в табличных частях для различных видов документов (приходов / расходов / ремонтных нарядов etc).
|
|
|
|
| |
Пост N: 3174
Зарегистрирован: 17.05.05
|
|
Отправлено: 26.05.13 10:19. Заголовок: p519446 пишет: Я та..
p519446 пишет: цитата: | Я так понял, надо будет собрать по каждой таблице, интенсивно участвующей в отчетах, статистику по средней длине записи (с учетом содержимого memo, судя по всему). Ну, и среднее число строк в табличных частях для различных видов документов (приходов / расходов / ремонтных нарядов etc). |
| Да
|
|
|
|
| |
Пост 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)
|
|
|
|
| |
Пост N: 145
Зарегистрирован: 07.08.06
|
|
Отправлено: 26.05.13 10:27. Заголовок: кхе! тебе хорошо, у ..
кхе! тебе хорошо, у тебя memo-полей нету... ;-) мну надо будет по-другому делать: обмолотить за последние год-два все записи, собрать статистику по длине с учетом мемо, а затем применить одну рекурсивную процедурку для выкидывания "нетипичных значений" (флуктуаций), чтобы получить достоверные значения среднего.
|
|
|
|
| |
Пост 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-полем. Результаты, скорее всего, будут "гораздо другие" (и гораздо отвратительнее в плане производительности).
|
|
|
|
| |
Пост N: 3176
Зарегистрирован: 17.05.05
|
|
Отправлено: 26.05.13 22:34. Заголовок: p519446 пишет: Резу..
p519446 пишет: цитата: | Результат сложил в эксель, вот тынц: http://yadi.sk/d/N9qJbPkd5C9El (этот файлик размером 19 Кб лежит на яндекс.диске, так что храниться будет вечно). |
| Ой, что-то сломалось… Открыть документ не удалось. Пожалуйста, повторите попытку позже.
|
|
|
|
|
| |
Пост N: 147
Зарегистрирован: 07.08.06
|
|
Отправлено: 27.05.13 00:28. Заголовок: Dima пишет: Открыть..
Dima пишет: цитата: | Открыть документ не удалось. Пожалуйста, повторите попытку позже. |
|
гм... у мну открылось ОК еще с двух машин... ну, вот еще одна, уже на .rar-файл: http://yadi.sk/d/gwE9MhCo5CVGm
|
|
|
|
| |
Пост 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 Это эксельный файл с двумя листами. В первом листе - результаты *без* мемо, но также скопированы для удобства сравнивания результаты теста *с* мемо. Во втором листе - наоборот, слева указаны сведения по тесту *с* мемо, справа - добавлены данные из первого листа. "Желаю приятного просмотра" :-)
|
|
|
|
| |
Пост N: 149
Зарегистрирован: 07.08.06
|
|
Отправлено: 27.05.13 01:21. Заголовок: PS. на всякий случай..
|
|
|
|
| |
Пост 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 ?
|
|
|
|
| |
Пост N: 3177
Зарегистрирован: 17.05.05
|
|
Отправлено: 27.05.13 13:38. Заголовок: p519446 пишет: Прот..
p519446 пишет: цитата: | Протестировал с bli exe ipx 48, запустил с 64. Пока не вижу разницы. |
| я тоже не увидел
|
|
|
|
| |
Пост 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 строк.
|
|
|
|
| |
Пост N: 3178
Зарегистрирован: 17.05.05
|
|
Отправлено: 27.05.13 17:11. Заголовок: p519446 пишет: Заме..
p519446 пишет: цитата: | Заметно, впрочем, что наилучшие показатели будут при ax_cacherecords() до 100 строк |
| это типа на глазок ? при такой установке и кол-ве записей в базе менее 100 прога у тебя упадет
|
|
|
|
| |
Пост 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)
|
|
|
|
| |
Пост N: 153
Зарегистрирован: 07.08.06
|
|
Отправлено: 27.05.13 21:05. Заголовок: PS. Была еще идея пр..
PS. Была еще идея проверить (вместо 'n' в ax_cacherecords()) влияние установки в ads.cfg COMPRESSION = always и пересборки клиента с соотв-щей библой. Но хорошо, что глянул в свои же комменты в этом ads.cfg: оказывается ads.nlm может заваливаться при этом с какой-то ошибкой, связанной с его стеком. В общем, стрёмно это как бэ :-)
|
|
|
Ответов - 22
, стр:
1
2
All
[только новые]
|
|