|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Имеется некая БД, которая крутится под Cache 2009. При доступе к этой БД через ECP все происходит в разы, если не в десятки раз, медленнее, чем при обычном локальном доступе. Уже вроде все проверили. Сеть работает нормально, файлы копируются без проблем. Приложение, написанное на С++, взаимодействует с БД одинаковым образом. Что еще может так замедлять доступ через ECP? Виктор ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 15:06 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Hisbreht Victor, Ну как бы логично, что работа через ECP медленнее, причем намного, по сравнению с доступом к локальной базе. Вопрос в том, что именно вы делаете с ECP? Некоторые операции, например, $incremet, lock (соответственно, вставка или апдейт строк таблиц) вызывают синхронизацию данных при каждой операции, что кардинально замедляет скорость. Если просто чтение, то тут более-менее должно быть нормально, данные будут кэшироваться и в итоге читаться из локального кэша. Еще зависит от версии, вроде бы в новых версиях работу с ECP обещали сделать получше. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 15:22 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Hisbreht Victor, запись без инкрементов и блокировок будет тоже достаточно быстрой. Если все-таки инкремент необходим, попробуйте заменить его $sequence ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 15:23 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Замедление, конечно, было ожидаемо, но не такое. Блок А.Н.Hisbreht Victor, запись без инкрементов и блокировок будет тоже достаточно быстрой. Если все-таки инкремент необходим, попробуйте заменить его $sequence Справка по 2009 $sequence не находит. Это получается надо на новую версию переходить? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 15:35 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Наиболее частые ошибки конфигурирования ECP: Мощный (по кол-ву ядер) сервер данных (СБД), слабые серверы приложений СП. Должно быть наоборот: приложения работают на СП. Недостаточно большой кэш данных на СП. Медленная сеть между СП и СБД. Должна быть >= 1000BaseT. Парадокс: менее 4 СП. Представитель ISC откровенно признался мне, что в таких случаях лучше применить вертикальное масштабирование. Существует тенденция отказа от ECP, когда технически возможно купить сервер, который сможет стать СБД+СП "в одном флаконе". Однако вряд ли малое количество СП снижает скорость работы на отдельно взятом СП; это лишь архитектурный изъян. Наиболее частые ошибки программирования в среде ECP: Использование full-сканов; если без них никак, то код, их выполняющий, должен запускаться удалённо на СБД или вообще на отдельном сервере (Reporting Async Mirroring Member). Использование bit-map индексов; неактуально, начиная с 2017.1. Использование "нормальных" глобалов в тех случаях, когда можно использовать временные или приватные. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 16:49 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Hisbreht Victor, в свое время (кстати, на 2009) если нужно было залить много данных для ECP, то разрабатывали правила генерации ID, чтобы они не повторились на разных серверах, создавали данные локально, а затем их просто сливали через merge. Решает проблему кардинально :-) К тому же, логика $sequence не такая уж сложная, если хотите, можно ее самим реализовать, и даже подзаточить именно под ваши условия. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 20:40 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Hisbreht Victor, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Вот как-то так. Это демка, в рабочей эксплуатации не использовал. Если понравится, вызов программы нужно будет переделать, но суть, я думаю, ясна. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2017, 22:25 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Виктор, я бы порекомендовал Вам в первую очередь последить во время передачи данных за таблицей блокировок на одном и другом Cache-сервере. Если их аномально много и они подолгу висят - это уже будет повод к размышлению, почему так происходит и что можно изменить. Ровно 10 лет назад, в сентябре 2007 года (у нас тогда появился первый клиент, для которого пришлось разрабатывать решение с использованием ECP), я нашел устойчиво воспроизводимый баг в реализации ECP, приводящий к неустранимой блокировке на одном из серверов. Баг был подтвержден в штаб-квартире и исправлен. Но и в архитектуру нашего решения тоже пришлось внести изменения с учетом этих блокировок. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2017, 18:56 |
|
Медленная работа через ECP
|
|||
---|---|---|---|
#18+
Всем спасибо за советы. Кое что почерпнул для себя. $Sequence действительно дает ускорение, хотя и не всегда приемлемо (в некоторых случаях "дыры" в нумерации, которые она вроде как может создавать, неприемлемы). С блокировками никаких проблем. Все по делу. И что интересно, одна из причин тормозов оказалась неожиданной. Дело было в том, что другое приложение подключалось через ECP к другой базе но на том же компьютере. При этом на клиенте создавалась новая запись для ECP сервера. В результате получалось два канала доступа к одному и тому же компьютеру. После перевода удаленных БД на один ECP сервер и удаления лишней записи в "ECP настройках" скорость заметно выросла. Интересно, это у меня фазы луны так совпали, или это имеет фундаментальное обоснование? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 22:24 |
|
|
start [/forum/topic.php?fid=39&msg=39500359&tid=1556321]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 148ms |
0 / 0 |