Автор | Сообщение |
|
| |
Пост N: 456
Зарегистрирован: 08.07.06
|
|
Отправлено: 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
|
|
|
Новых ответов нет
[см. все]
|
|
|
| |
Пост N: 254
Зарегистрирован: 03.12.08
|
|
Отправлено: 25.06.15 14:47. Заголовок: Sergy а как со скоро..
Sergy а как со скоростью при .CDX индексах ??
|
|
|
|
| Администратор
|
Пост N: 3290
Зарегистрирован: 23.05.05
|
|
Отправлено: 25.06.15 14:48. Заголовок: Дык работа с БД в ре..
Дык работа с БД в режиме файл-сервер сама по себе есть ретро-стиль :) чтобы избежать операций LOCK INDEX FILE и UNLOCK INDEX FILE при каждом skip, можно в начале всего цикла выдать: dbOrderInfo(DBOI_READLOCK,,, .t.) а в конце: dbOrderInfo(DBOI_READLOCK,,, .f.) для некоторых ОС это дает большой рост производительности.
|
|
|
|
| |
Пост N: 457
Зарегистрирован: 08.07.06
|
|
Отправлено: 26.06.15 12:34. Заголовок: Softlog86 пишет: Se..
Softlog86 пишет: цитата: | Sergy а как со скоростью при .CDX индексах ?? |
| Не пробовал, тк вся работа в NTX. Вот хотел "закинуть удочку", может кто-то использует и те и другие, чтобы сравнить...
|
|
|
|
| |
Пост N: 458
Зарегистрирован: 08.07.06
|
|
Отправлено: 26.06.15 12:37. Заголовок: Pasha пишет: Дык ра..
Pasha пишет: цитата: | Дык работа с БД в режиме файл-сервер сама по себе есть ретро-стиль |
| Не могу не согласиться. цитата: | чтобы избежать операций LOCK INDEX FILE и UNLOCK INDEX FILE при каждом skip, можно в начале всего цикла выдать: dbOrderInfo(DBOI_READLOCK,,, .t.) а в конце: dbOrderInfo(DBOI_READLOCK,,, .f.) для некоторых ОС это дает большой рост производительности. |
| Если не ошибаюсь, этот метод называется DIRTY_READ или что-то вроде того... Нужно будет попробовать - в большинстве отчетов ведь не требуется актуальность "до секунды в реальном времени".
|
|
|
|
| Администратор
|
Пост N: 3291
Зарегистрирован: 23.05.05
|
|
Отправлено: 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 операции выполняются гораздо быстрее.
|
|
|
|
| |
Пост N: 98
Зарегистрирован: 24.04.13
|
|
Отправлено: 26.06.15 14:27. Заголовок: Sergy, попробуй на г..
Sergy, попробуй на гигабитной сети "серверный" вызов.
|
|
|
|
| постоянный участник
|
Пост N: 1075
Зарегистрирован: 27.01.07
|
|
Отправлено: 26.06.15 16:13. Заголовок: azoo пишет: попробу..
azoo пишет: цитата: | попробуй на гигабитной сети "серверный" вызов. |
| +1 Даже самый паршивый старый диск сможет читать/писать со скоростью 30Мбайт/с Новый (свежий) диск - более 100 Мбайт/с 100-мегабитная сетка - максимум 12Мбайт/с, т.е. медленнее старого диска. А если учесть, что работают сразу несколько станций, то еще медленней. Гигабитная сетка - почти как новый винт (конечно тоже зависит от трафика) :) Вывод: всё как обычно упирается в физические ограничения среды передачи. Не зря RDP придумали... :) ps. Еще один момент: при записи на локальный диск операционная система кэширует данные, что еще больше увеличивает скорость. А при чтении может использоваться упреждающее чтение, что тоже иногда положительно сказывается на производительности. Само собой, при доступе через сеть эти механизмы не работают.
|
|
|
|
| |
Пост N: 459
Зарегистрирован: 08.07.06
|
|
Отправлено: 26.06.15 16:56. Заголовок: azoo пишет: Sergy, ..
azoo пишет: цитата: | Sergy, попробуй на гигабитной сети "серверный" вызов. |
| Сеть давно гигибитная. Таблица 200 мегов - заливается локально за 3-4 секунды.
|
|
|
|
| |
Пост N: 99
Зарегистрирован: 24.04.13
|
|
Отправлено: 26.06.15 17:01. Заголовок: PSP, у меня скорость..
PSP, у меня скорость по сетке 65-70 мб/сек. Сомневаюсь что старый диск даст 30 мб/сек.
|
|
|
|
| постоянный участник
|
Пост N: 1076
Зарегистрирован: 27.01.07
|
|
Отправлено: 26.06.15 17:02. Заголовок: azoo пишет: Сомнева..
azoo пишет: цитата: | Сомневаюсь что старый диск даст 30 мб/сек. |
| Не сомневайтесь )))
|
|
|
|
| |
Пост N: 460
Зарегистрирован: 08.07.06
|
|
Отправлено: 28.06.15 20:10. Заголовок: Pasha пишет: чтобы ..
Pasha пишет: цитата: | чтобы избежать операций LOCK INDEX FILE и UNLOCK INDEX FILE при каждом skip, можно в начале всего цикла выдать: dbOrderInfo(DBOI_READLOCK,,, .t.) а в конце: dbOrderInfo(DBOI_READLOCK,,, .f.) для некоторых ОС это дает большой рост производительности. |
| Проанализировал эти установки, прошелся поиском по нашему форуму: этот вариант точно не годится: пока один чел делает выборку для отчета, другие десять не смогут добавить/обновить записи в индексе.
|
|
|
|
|
| |
Пост N: 4990
Зарегистрирован: 17.05.05
|
|
Отправлено: 28.06.15 20:12. Заголовок: Sergy Варианты: Let..
Sergy Варианты: LetoDB , ADS.
|
|
|
|
| постоянный участник
|
Пост N: 4322
Зарегистрирован: 12.09.06
|
|
Отправлено: 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 и сравнить.
|
|
|
|
| |
Пост N: 140
Зарегистрирован: 24.04.13
|
|
Отправлено: 18.12.19 09:11. Заголовок: Очень сильно замедля..
Очень сильно замедляется работа когда БД открыта одновременно несколькими приложениями. Помогает простое копирование даже не на локальный диск, а на сетевой COPY FILE aaa.dbf. to aaa_temp.dbf. и потом открывать aaa_temp. В чём глюк? ОС файл-сервера Windows Server 2008.
|
|
|
|
| Администратор
|
Пост N: 3907
Зарегистрирован: 23.05.05
|
|
Отправлено: 18.12.19 10:11. Заголовок: azoo пишет: Очень с..
azoo пишет: цитата: | Очень сильно замедляется работа когда БД открыта одновременно несколькими приложениями. |
| При чтении каждой записи в shared режиме выполняется блокировка индекса. В современных ОС это операция небыстрая
|
|
|
|
| постоянный участник
|
Пост N: 6552
Зарегистрирован: 12.09.06
|
|
Отправлено: 18.12.19 11:47. Заголовок: Sergy пишет: С одно..
Sergy пишет: цитата: | С одной стороны - круто и офигенно для отчетов выходит, с другой - какой-то ретро-стиль получается... |
| Переходи на LetoDB Там выборка и суммирование ещё быстрей делается... https://abonent4.ru/letodb/
|
|
|
|
| постоянный участник
|
Пост N: 1577
Зарегистрирован: 27.01.07
|
|
Отправлено: 20.12.19 20:18. Заголовок: azoo, не нужно в чуж..
azoo, не нужно в чужих, да ещё и старых темах писать. А то Андрей отвечает на посты 4-х летней давности)))
|
|
|
|
| |
Пост N: 7153
Зарегистрирован: 17.05.05
|
|
Отправлено: 20.12.19 21:36. Заголовок: PSP :sm64:..
PSP
|
|
|
|
| постоянный участник
|
Пост N: 1578
Зарегистрирован: 27.01.07
|
|
Отправлено: 20.12.19 21:38. Заголовок: Андрей, это - шутка...
Андрей, это - шутка. Правда прикольно выглядит (для меня))) Без обид, ок?)
|
|
|
|
| постоянный участник
|
Пост N: 6555
Зарегистрирован: 12.09.06
|
|
Отправлено: 20.12.19 23:59. Заголовок: PSP пишет: Андрей, ..
PSP пишет: цитата: | Андрей, это - шутка. Правда прикольно выглядит (для меня))) Без обид, ок?) |
| Я попробовал ЛетоДБ и очень им восторгаюсь. Использую теперь у себя как на сервере, так и в инете для передачи баз. Раньше тоже сталкивался с долгим отбором на своих базах, после перехода на ЛетоДБ стало намного легче. Вот и делюсь опытом для других, чтобы попробовали и впечатлились технологией клиент-сервер !
|
|
|
|