Отправлено: 25.06.15 13:53. Заголовок: К вопросу о сетевой производительности...

Недавно прочитал пост Przemek о сути происходящих процессов во время банального DO WHILE !EOF() ; SKIP ; ENDDO в случае работы с активным индексом: _https://groups.google.com/forum/#!starred/harbour-users/xA5WrwYX-5Y

цитата:

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.

Посмотрев на всю эту кухню, решил в в одном из расчетов заменить "серверный" вызов:

USE (cTable) INDEX (cTable) READONLY NEW  
 SEEK ... 
 DO WHILE (MyExp) 
  SKIP 
 ENDDO

на:

COPY FILE (work_dir+cTable) TO (local_dir+cTable) 
 USE (local_dir+cTable) NEW 
 DO WHILE !EOF() 
  IF (MyExpression) 
   /// то, что раньше искалось по индексу 
  ENDIF 
  SKIP 
 ENDDO

... и офигел... раньше выборка ~10'000 записей по индексу (в сети с 15-25 активных юзеров) в таблице 200 мегов занимала больше минуты.
Сейчас: загрузка локально около 4х секунд, локальный skip с выборкой по всем записям (~ 3млн200тыс) - 10 секунд.

Итого - выигрыш примерно в 4-5 раз...

С одной стороны - круто и офигенно для отчетов выходит, с другой - какой-то ретро-стиль получается...

PS: DBFNTX

 Отправлено: 25.06.15 14:47. Заголовок: Sergy а как со скоро..

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

 Отправлено: 25.06.15 14:48. Заголовок: Дык работа с БД в ре..

Дык работа с БД в режиме файл-сервер сама по себе есть ретро-стиль :)

чтобы избежать операций
LOCK INDEX FILE
и
UNLOCK INDEX FILE
при каждом skip,
можно в начале всего цикла выдать:
dbOrderInfo(DBOI_READLOCK,,, .t.)
а в конце:
dbOrderInfo(DBOI_READLOCK,,, .f.)

для некоторых ОС это дает большой рост производительности.

 Отправлено: 26.06.15 12:34. Заголовок: Softlog86 пишет: Se..

Softlog86 пишет:

цитата:

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

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

 Отправлено: 26.06.15 12:37. Заголовок: Pasha пишет: Дык ра..

Pasha пишет:

цитата:

Дык работа с БД в режиме файл-сервер сама по себе есть ретро-стиль

Не могу не согласиться.

цитата:

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

Если не ошибаюсь, этот метод называется DIRTY_READ или что-то вроде того... Нужно будет попробовать - в большинстве отчетов ведь не требуется актуальность "до секунды в реальном времени".

 Отправлено: 26.06.15 13:55. Заголовок: Пару слов о том, как..

Пару слов о том, как выполняется 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 операции выполняются гораздо быстрее.

 Отправлено: 26.06.15 14:27. Заголовок: Sergy, попробуй на г..

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

 Отправлено: 26.06.15 16:13. Заголовок: azoo пишет: попробу..

azoo пишет:

цитата:

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

+1

Даже самый паршивый старый диск сможет читать/писать со скоростью 30Мбайт/с

Новый (свежий) диск - более 100 Мбайт/с

100-мегабитная сетка - максимум 12Мбайт/с, т.е. медленнее старого диска. А если учесть, что работают сразу несколько станций, то еще медленней.

Гигабитная сетка - почти как новый винт (конечно тоже зависит от трафика) :)


Вывод: всё как обычно упирается в физические ограничения среды передачи. Не зря RDP придумали... :)

ps. Еще один момент: при записи на локальный диск операционная система кэширует данные, что еще больше увеличивает скорость. А при чтении может использоваться упреждающее чтение, что тоже иногда положительно сказывается на производительности. Само собой, при доступе через сеть эти механизмы не работают.

 Отправлено: 26.06.15 16:56. Заголовок: azoo пишет: Sergy, ..

azoo пишет:

цитата:

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

Сеть давно гигибитная.
Таблица 200 мегов - заливается локально за 3-4 секунды.

 Отправлено: 26.06.15 17:01. Заголовок: PSP, у меня скорость..

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

 Отправлено: 26.06.15 17:02. Заголовок: azoo пишет: Сомнева..

azoo пишет:

цитата:

Сомневаюсь что старый диск даст 30 мб/сек.

Не сомневайтесь )))

 Отправлено: 28.06.15 20:10. Заголовок: Pasha пишет: чтобы ..

Pasha пишет:

цитата:

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

Проанализировал эти установки, прошелся поиском по нашему форуму: этот вариант точно не годится: пока один чел делает выборку для отчета, другие десять не смогут добавить/обновить записи в индексе.

 Отправлено: 28.06.15 20:12. Заголовок: Sergy Варианты: Let..

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

 Отправлено: 29.06.15 03:50. Заголовок: Sergy пишет: Не про..

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 и сравнить.

 Отправлено: 18.12.19 09:11. Заголовок: Очень сильно замедля..

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

 Отправлено: 18.12.19 10:11. Заголовок: azoo пишет: Очень с..

azoo пишет:

цитата:

Очень сильно замедляется работа когда БД открыта одновременно несколькими приложениями.

При чтении каждой записи в shared режиме выполняется блокировка индекса. В современных ОС это операция небыстрая

 Отправлено: 18.12.19 11:47. Заголовок: Sergy пишет: С одно..

Sergy пишет:

цитата:

С одной стороны - круто и офигенно для отчетов выходит, с другой - какой-то ретро-стиль получается...

Переходи на LetoDB
Там выборка и суммирование ещё быстрей делается...
https://abonent4.ru/letodb/

 Отправлено: 20.12.19 20:18. Заголовок: azoo, не нужно в чуж..

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

 Отправлено: 20.12.19 21:36. Заголовок: PSP :sm64:..

PSP

 Отправлено: 20.12.19 21:38. Заголовок: Андрей, это - шутка...

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

 Отправлено: 20.12.19 23:59. Заголовок: PSP пишет: Андрей, ..

PSP пишет:

цитата:

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

Я попробовал ЛетоДБ и очень им восторгаюсь.
Использую теперь у себя как на сервере, так и в инете для передачи баз.

Раньше тоже сталкивался с долгим отбором на своих базах, после перехода на ЛетоДБ стало намного легче.
Вот и делюсь опытом для других, чтобы попробовали и впечатлились технологией клиент-сервер !