К вопросу о сетевой производительности...

Форум » [x]Harbour » К вопросу о сетевой производительности... » Ответить

К вопросу о сетевой производительности...

Sergy: Недавно прочитал пост Przemek о сути происходящих процессов во время банального DO WHILE !EOF() ; SKIP ; ENDDO в случае работы с активным индексом: _https://groups.google.com/forum/#!starred/harbour-users/xA5WrwYX-5Y [quote]Direct file IO access (also with HBNETIO used as FILE IO redirector) needs much more operations, i.e. for SKIP with active index it needs: LOCK INDEX FILE READ INDEX HEADER WITH UPDATE COUNTER TO CHECK IF IT WAS CHANGED IF INDEX WAS CHANGED SEEK CURRENT RECORD * TAKE NEXT/PREV RECORD NUMBER FROM INDEX PAGE READ RECORD BODY IF RECORD IS NOT VISIBLE (DELETED OR FILTERED) GOTO (*) UNLOCK INDEX FILE Each (*) operation may cause additional IO request. SEEK operation has in practice comparable cost to SKIP. [/quote] Посмотрев на всю эту кухню, решил в в одном из расчетов заменить "серверный" вызов: [pre2]USE (cTable) INDEX (cTable) READONLY NEW SEEK ... DO WHILE (MyExp) SKIP ENDDO[/pre2] на: [pre2]COPY FILE (work_dir+cTable) TO (local_dir+cTable) USE (local_dir+cTable) NEW DO WHILE !EOF() IF (MyExpression) /// то, что раньше искалось по индексу ENDIF SKIP ENDDO[/pre2] ... и офигел... раньше выборка ~10'000 записей по индексу (в сети с 15-25 активных юзеров) в таблице 200 мегов занимала больше минуты. Сейчас: загрузка локально около 4х секунд, локальный skip с выборкой по всем записям (~ 3млн200тыс) - 10 секунд. Итого - выигрыш примерно в 4-5 раз... С одной стороны - круто и офигенно для отчетов выходит, с другой - какой-то ретро-стиль получается... PS: DBFNTX

Ответов - 20

Softlog86: Sergy а как со скоростью при .CDX индексах ??

Pasha: Дык работа с БД в режиме файл-сервер сама по себе есть ретро-стиль :) чтобы избежать операций LOCK INDEX FILE и UNLOCK INDEX FILE при каждом skip, можно в начале всего цикла выдать: dbOrderInfo(DBOI_READLOCK,,, .t.) а в конце: dbOrderInfo(DBOI_READLOCK,,, .f.) для некоторых ОС это дает большой рост производительности.

Sergy: Softlog86 пишет: Sergy а как со скоростью при .CDX индексах ?? Не пробовал, тк вся работа в NTX. Вот хотел "закинуть удочку", может кто-то использует и те и другие, чтобы сравнить...

Sergy: Pasha пишет: Дык работа с БД в режиме файл-сервер сама по себе есть ретро-стиль Не могу не согласиться. чтобы избежать операций LOCK INDEX FILE и UNLOCK INDEX FILE при каждом skip, можно в начале всего цикла выдать: dbOrderInfo(DBOI_READLOCK,,, .t.) а в конце: dbOrderInfo(DBOI_READLOCK,,, .f.) для некоторых ОС это дает большой рост производительности. Если не ошибаюсь, этот метод называется DIRTY_READ или что-то вроде того... Нужно будет попробовать - в большинстве отчетов ведь не требуется актуальность "до секунды в реальном времени".

Pasha: Пару слов о том, как выполняется skip по индексу в случае использования letodb: 1. На стороне клиента. Посылается запрос к серверу, и принимается ответ - буфер с текущей записью и следующими записями в количестве nSkipBuffer (по умолчанию 10). Для последующих <nSkipBuffer-1> операций skip запрос к серверу не посылается, а запись просто берется из буфера на клиенте. Для большого цикла nSkipBuffer можно задать достаточно большим. 2. На стороне сервера. Поскольку файл открыт монопольно, то выполняются только такие операции: * TAKE NEXT/PREV RECORD NUMBER FROM INDEX PAGE READ RECORD BODY IF RECORD IS NOT VISIBLE (DELETED OR FILTERED) GOTO (*) и так далее, для <nSkipBuffer> записей. Блокировка индекса не нужна, и, поскольку файл открыт локально, все i/o операции выполняются гораздо быстрее.

azoo: Sergy, попробуй на гигабитной сети "серверный" вызов.

PSP: azoo пишет: попробуй на гигабитной сети "серверный" вызов. +1 Даже самый паршивый старый диск сможет читать/писать со скоростью 30Мбайт/с Новый (свежий) диск - более 100 Мбайт/с 100-мегабитная сетка - максимум 12Мбайт/с, т.е. медленнее старого диска. А если учесть, что работают сразу несколько станций, то еще медленней. Гигабитная сетка - почти как новый винт (конечно тоже зависит от трафика) :) Вывод: всё как обычно упирается в физические ограничения среды передачи. Не зря RDP придумали... :) ps. Еще один момент: при записи на локальный диск операционная система кэширует данные, что еще больше увеличивает скорость. А при чтении может использоваться упреждающее чтение, что тоже иногда положительно сказывается на производительности. Само собой, при доступе через сеть эти механизмы не работают.

Sergy: azoo пишет: Sergy, попробуй на гигабитной сети "серверный" вызов. Сеть давно гигибитная. Таблица 200 мегов - заливается локально за 3-4 секунды.

azoo: PSP, у меня скорость по сетке 65-70 мб/сек. Сомневаюсь что старый диск даст 30 мб/сек.

PSP: azoo пишет: Сомневаюсь что старый диск даст 30 мб/сек. Не сомневайтесь )))

Sergy: Pasha пишет: чтобы избежать операций LOCK INDEX FILE и UNLOCK INDEX FILE при каждом skip, можно в начале всего цикла выдать: dbOrderInfo(DBOI_READLOCK,,, .t.) а в конце: dbOrderInfo(DBOI_READLOCK,,, .f.) для некоторых ОС это дает большой рост производительности. Проанализировал эти установки, прошелся поиском по нашему форуму: этот вариант точно не годится: пока один чел делает выборку для отчета, другие десять не смогут добавить/обновить записи в индексе.

Dima: Sergy Варианты: LetoDB , ADS.

Andrey: Sergy пишет: Не пробовал, тк вся работа в NTX. Вот хотел "закинуть удочку", может кто-то использует и те и другие, чтобы сравнить... Бери и тести сам CDX (а можешь и Leto) - прога пока сырая ещё, но я хочу сделать разные алгоритмы расчета. Сам алгоритм CalcMaster() в use_base.prg Кол-во записей тестовой базы назначаешь сам по кнопке с колёсиком. Только старую базу не забудь удалить, а то новую не создаст. Прога здесь - https://cloud.mail.ru/public/Cxey/WuVd7UY9M Алгоритм простой - выборка по SEEK и суммирование по 7 полям и запись этих 7 полей в локальную базу на компе пользователя. База 100 000 записей с мемо-полями: 120 Мб Расчет по простому индексу 13 позиций: 1) локальная DBFCDX - 00:01:10 2) локальная LETO - 00:01:11 3) интернет LETO - 00:04:37 Если база считается интернет + LETO, иногда подвисает при записи в локальную базу результатов. Странно всего 7 полей записать, а подвисает так что в окне программы пишет (программа не отвечает). Может и не там происходит подвисание. База 1 000 000 записей с мемо-полями: 1,2 Гб Расчет по простому индексу 13 позиций: 1) локальная DBFCDX - 00:06:38 2) локальная LETO - 00:06:35 3) интернет LETO - 00:34:45 Если база считается интернет + LETO, то постоянно подвисает при записи результатов. При суммировании строка показывается (мастер+ кода) быстро. Но это пока сырая программа, нужно дорабатывать. Пока вообще не задействована выборка Leto Можешь переделать код из CalcMaster() в use_base.prg под NTX и сравнить.

azoo: Очень сильно замедляется работа когда БД открыта одновременно несколькими приложениями. Помогает простое копирование даже не на локальный диск, а на сетевой COPY FILE aaa.dbf. to aaa_temp.dbf. и потом открывать aaa_temp. В чём глюк? ОС файл-сервера Windows Server 2008.

Pasha: azoo пишет: Очень сильно замедляется работа когда БД открыта одновременно несколькими приложениями. При чтении каждой записи в shared режиме выполняется блокировка индекса. В современных ОС это операция небыстрая

Andrey: Sergy пишет: С одной стороны - круто и офигенно для отчетов выходит, с другой - какой-то ретро-стиль получается... Переходи на LetoDB Там выборка и суммирование ещё быстрей делается... https://abonent4.ru/letodb/

PSP: azoo, не нужно в чужих, да ещё и старых темах писать. А то Андрей отвечает на посты 4-х летней давности)))

Dima: PSP

PSP: Андрей, это - шутка. Правда прикольно выглядит (для меня))) Без обид, ок?)

Andrey: PSP пишет: Андрей, это - шутка. Правда прикольно выглядит (для меня))) Без обид, ок?) Я попробовал ЛетоДБ и очень им восторгаюсь. Использую теперь у себя как на сервере, так и в инете для передачи баз. Раньше тоже сталкивался с долгим отбором на своих базах, после перехода на ЛетоДБ стало намного легче. Вот и делюсь опытом для других, чтобы попробовали и впечатлились технологией клиент-сервер !

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