Добрый день!
Прошу помочь разобраться в вопросе.
Перенёс серверную БД с H2 на MSSQL, при этом сервер приложений и сама Руна остались на прежней машине, а БД перешла на серверную машину. Обновил приложение до последней ревизии с GitHub. После проделанных действий от пользователей периодически стали сыпаться претензии по скорости работы, при этом у себя под учёткой Администратора я таких проблем не наблюдаю.
Тормоза наблюдаются у пользователей когда:
1. происходит авторизация и соответственно открытие Списка заданий, если в нём много задач, более 30. При чём происходит только в первый раз, после запуска приложения, в дальнейшем скорость приемлимая.
2. также при переходе в Запущенные процессы, если там отображается более 30 процессов.
3. и при запуске нового процесса.
Подскажите, есть ли какие то механизмы ускорить работу приложения. При работе на прежней БД (H2) расположенной на том же компе, что и приложение таких сильных тормозов не наблюдалось.
Спасибо,
с уважением, Артур.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Подскажите, есть ли какие то механизмы ускорить работу приложения.
Для этих целей у нас есть два вида кеширования задач. - Есть обычное кеширование, а есть еще smart-кеширование. Они "включаются" соответствующими настройками.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
происходит авторизация и соответственно открытие Списка заданий, если в нём много задач, более 30. При чём происходит только в первый раз, после запуска приложения, в дальнейшем скорость приемлемая.
В этот момент происходит обращение к базе и строится кеш. При последующих вызовах списка задач используется построенный кеш и обращение к базе происходит редко.
также при переходе в Запущенные процессы, если там отображается более 30 процессов.
Похоже всё дело в пользовательских фильтрах, Без фильтров работает мгновенно
Какие условия вы устанавлеваете в фильтрах? Для некоторых условий запросы могут выполняться долго.
Regards,
Andrei
Last edit: Andrei Mikheev 2016-08-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Добрый день.
Есть http://server/monitoring, в котором можно посмотреть статистику выполнения (web, запросов в БД). Зафиксирована ли там медленная работа и где именно? Какие задержки возникают, которые вы квалифицируете как тормоза? Сколько БП в системе и какое кол-во заданий во время тормозов? Как настроены фильтры - тоже сообщите.
Если то же самое не тормозило на локальной H2 - то возможно неправильно настроена сеть либо MSSQL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Зафиксирована ли там медленная работа и где именно?
Прикладываю статистику в pdf. Я к сожалению не разбираюсь.
Какие задержки возникают, которые вы квалифицируете как тормоза?
Задержка возникает, когда у пользователя настроен фильтр в списке заданий, при входе в систему в первый раз. При этом в фильтре выводится переменные из БП, не менее трёх. И применяется фильтр по наименованию процесса. В списке заданий 30 или более заданий. При количестве заданий ~30 задержка ~5 сек., при 100 ~ 34 сек.
Во втором случае, задержка возникает, когда пользователь завершает задание и соответственно возвращается к списку заданий. Вот в этом случае вопрос, если smart-кэширование подгружает только изменения, то почему в момент выполнения задания руна подвисает так же, как когда кэширует все задания пользователя, ведь изменилось только одно?
Сколько БП в системе и какое кол-во заданий во время тормозов?
В системе 21 БП и subБП
Всего в Запущенных 22840 из них незавершённых 1424
У пользователя, от которого приходит замечание на скорость работы, в списке заданий 30 заданий.
Как настроены фильтры - тоже сообщите.
В фильтрах присутствуют переменные процессов типа Строка, не менее трёх . Чаще всего также присутствует фильтр по наименованию процесса.
Если то же самое не тормозило на локальной H2 - то возможно неправильно настроена сеть либо MSSQL.
Не могу сейчас точно сказать, было ли то же самой на H2, может быть просто пользователь ничего не говорил. Я, работая под администратором, наоборот ощутил ускорение работы от перехода на MSSQL, но у меня нет такого количества заданий :)
Может быть помогло бы ограничение количества выводимых экземпляров процессов на странице "Список заданий", как это сделано в "Запущенных процессах"?
Не могли бы Вы реализовать данный фильтр?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Прикладываю статистику в pdf. Я к сожалению не разбираюсь.
Посмотрел, в нём не зафиксировано каких-то конкретных проблем.
Вот в этом случае вопрос, если smart-кэширование подгружает только изменения, то почему в момент выполнения задания руна подвисает так же, как когда кэширует все задания пользователя, ведь изменилось только одно?
Оно не настолько smart. Оно сбрасывает не все кеши заданий, а только те, на которые повлияла операция, но полностью. Можно подумать об его улучшении до изменений.
Может быть помогло бы ограничение количества выводимых экземпляров процессов на странице "Список заданий", как это сделано в "Запущенных процессах"? Не могли бы Вы реализовать данный фильтр?
Пейджинга в заданиях настоящего не будет, потому что список динамический (с учётом групп пользователей и замещений строится, не в БД).
Т.е. отдать на страницу 10 шт. из 100 можем, но перед отдачей список полный строится будет, так что нет смысла.
Я воспроизвёл у себя проблему (порядка 10 секунд на 120 заданий), думаю можно попрофилировать список заданий на поиск узкого места.
Вообще неплохо было бы добавить на страницу время её загрузки.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
При построении списка с выводом значений переменных процессов/заданий каждая переменная для каждого задания подгружается отдельным запросом в БД. Соответственно при построении списка из 30 заданий с 3 переменными ~ 100 запросов уходит в БД только для получения значений переменных При загрузке первый раз это происходит, так как кеш еще не работает. При выполнении задания кеш для пользователя, выполнившего задание так-же сбрасывается (он хранит уже построенный список и из-за изменений его требуется перестроить).
В статистике SQL очень не нравится запрос загрузки переменной (66% времени): select variable0_.ID as ID0_, variable0_.NAME as NAME0_, variable0_.VERSION as
VERSION0_, variable0_.CONVERTER as CONVERTER0_, variable0_.PROCESS_ID as PROCESS12_0_, variable0_.CREATE_DATE as
CREATE6_0_, variable0_.STRINGVALUE as STRINGVA7_0_, variable0_.LONGVALUE as LONGVALUE0_, variable0_.DOUBLEVALUE as
DOUBLEVA9_0_, variable0_.DATEVALUE as DATEVALUE0_, variable0_.BYTES as BYTES0_, variable0_.DISCRIMINATOR as
DISCRIMI1_0_ from BPM_VARIABLE variable0_ where variable0_.PROCESS_ID=? and variable0_.NAME=?
Посмотрите план запроса и какие там есть индексы. Скорее всего вопрос решится созданием индекса.
При работе на H2 проблем не было из-за того, что при работе БД в режиме in-memory колическтво отправляемых запросов не оказывает такого сильного влияния на производительность. При переезде на SQL количество запросов играет раль, так как задержки на передачу по сети намного больше чем в in-memory БД (даже если сама БД находит данные быстрее).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Я, честно говоря, не умею этого делать, поэтому неуверен, что правильную информацию Вам сейчас предоставлю (plsql.png).
Кстати, вчера решил проверить, при переносе из H2 в mssql я не выполнил скрипт, создающий индексы (index.sql) , вчера я его провёл. По ощущениям лучше не стало, даже по-моему, стало хуже.
Не хотелось бы торопиться с выводами, но сегодня ещё одна странная штука произошла. Решил перезагрузить комп с приложением - автоматом запустился check disk, похоже словил какие то ошибки на диске.. после загрузки runa стала работать значительно шустрее. Но пока не под нагрузкой, пользователи ещё не подошли. Пока наблюдаю. Возможно все же дело было в индексах
Last edit: Artur Nigmatullin 2016-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Оставлять БД без индексов это жестоко. При росте размеров она и винты все убъет постоянным чтением и самой ей будет плохо перелопачивать такой объем данных.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
а знаете. что самое странное.. я сверил в dbForge рабочую базу mssql и базу, которую руна автоматически создает если база пуста, так вот во вновь созданной автоматически mssql базе нет тех индексов которые я накатил из скрипта выше.. а скрипт я этот получил при анализе таблиц рабочей базы на H2 ..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Индексы создаются через hibernate и недолжны зависеть от БД. Где то должна быть ошибка - у нас есть инсталляции на MS SQL и там вроде таких проблем не было.
PS. Какие изменения после накатывания индексов?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
В списке заданий полльзователя 160 заданий, применён фильтр, в котором есть переменные из процесса (10 шт.), так же есть фильтрация по наименованию процесса, и группировка по одной из переменных процесса => первая авторизация занимается ~3-5сек, завершение задания и возврат к списку заданий занимает ~20-30сек... Так что, ещё остались вопросы к скорости работы, но стало лучше.
Скорость работы с большим списком заданий с несколькими переменными исправится только с исправлением кода - необходимо подружать переменные не по одной, а сразу все одним запросом. Последовательное выполнение запросов к БД занимает много времени.
Запланируем доработку и в будущем исправим.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Можно ещё попробовать 2 вещи:
1) использовать 1 кумулятивный индекс вместо 2 разных:
drop index RUNAWFE.IX_VARIABLE_NAME;
drop index RUNAWFE.FK_VARIABLE_PROCESS;
create index RUNAWFE.IX_VARIABLE_PROCESS_NAME on RUNAWFE.BPM_VARIABLE(PROCESS_ID,NAME);
2) т.к. при выполнении задания время ожидания пользователя включает не только построение списка, но и коммит транзакции, обеспечивающей прохождение точки управления по графу - можно попробовать использовать новый режим с более короткими транзакциями: http://www.runawfe.org/rus/doc/ProcessTransactions#ConfigurableBoundaries
Это улучшит ситуацию если после задания много элементов, на которых транзакция не оканчивается.
исправится только с исправлением кода - необходимо подружать переменные не по одной, а сразу все одним запросом.
Кеширование запроса этого не поможет?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) При работе на H2 проблем не было. То есть проблема не в получении данных в рамках БД как таковой, а в накладных расходах на выполнение запросов (сетевое взаимодействие). Один большой запрос, пусть даже он выгружает лишние данные намного выгоднее чем много мелких, которые грузят только то что нужно.
2) Это к построению списка заданий не относится, так что без коментария.
Можно попробовать включить кеш hibernate, но это только скрывает проблему и код все равно переписывать.
Нужно просто сделать правильную работу с данными. На момент загрузки переменных мы уже знаем все процессы и названия переменных для которых надо выполнить выгрузку. Один запрос в БД для выгрузки всех этих переменных в рамках процесса загрузки списка заданий будет дешев, сократит время выполнения (меньше deadlock) и т.п. В общем переписать код правильно даёт сплошные бенефиты.
Может быть там есть какие то ограничения, из-а которых такой запрос написать нельзя - но тогда будем думать дальше.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Применение кумулятивного индекса позволило немного ускорить работу ~18 сек.
drop index "dbo"."BPM_VARIABLE".IX_VARIABLE_NAME;
drop index "dbo"."BPM_VARIABLE".IX_VARIABLE_PROCESS;
create index IX_VARIABLE_PROCESS_NAME on "dbo"."BPM_VARIABLE"(PROCESS_ID,NAME);
Дело в том, что тестирую на действии процесса, в котором одним из выходов из действия является кнопкна "Сохранить", которая просто обновляет значения переменных и заново возвращает задание пользователю. Между выходом "Сохранить" и действием нет других узлов.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Добрый день!
Прошу помочь разобраться в вопросе.
Перенёс серверную БД с H2 на MSSQL, при этом сервер приложений и сама Руна остались на прежней машине, а БД перешла на серверную машину. Обновил приложение до последней ревизии с GitHub. После проделанных действий от пользователей периодически стали сыпаться претензии по скорости работы, при этом у себя под учёткой Администратора я таких проблем не наблюдаю.
Тормоза наблюдаются у пользователей когда:
1. происходит авторизация и соответственно открытие Списка заданий, если в нём много задач, более 30. При чём происходит только в первый раз, после запуска приложения, в дальнейшем скорость приемлимая.
2. также при переходе в Запущенные процессы, если там отображается более 30 процессов.
3. и при запуске нового процесса.
Подскажите, есть ли какие то механизмы ускорить работу приложения. При работе на прежней БД (H2) расположенной на том же компе, что и приложение таких сильных тормозов не наблюдалось.
Спасибо,
с уважением, Артур.
Похоже всё дело в пользовательских фильтрах, Без фильтров работает мгновенно
Для этих целей у нас есть два вида кеширования задач. - Есть обычное кеширование, а есть еще smart-кеширование. Они "включаются" соответствующими настройками.
Насколько я понимаю, по-умолчанию включено smart-кэширование, а обычное кэширование ещё сильнее замедлит работу?
Судя по документации
http://www.runawfe.org/rus/doc/ServerConfigurationGuide#cache.properties
и по тому, что я вижу в \wfe-core\src....\cache.properties
smart_cache=true
действительно по умолчанию включен smart
В этот момент происходит обращение к базе и строится кеш. При последующих вызовах списка задач используется построенный кеш и обращение к базе происходит редко.
Какие условия вы устанавлеваете в фильтрах? Для некоторых условий запросы могут выполняться долго.
Regards,
Andrei
Last edit: Andrei Mikheev 2016-08-17
Добрый день.
Есть http://server/monitoring, в котором можно посмотреть статистику выполнения (web, запросов в БД). Зафиксирована ли там медленная работа и где именно? Какие задержки возникают, которые вы квалифицируете как тормоза? Сколько БП в системе и какое кол-во заданий во время тормозов? Как настроены фильтры - тоже сообщите.
Если то же самое не тормозило на локальной H2 - то возможно неправильно настроена сеть либо MSSQL.
Прикладываю статистику в pdf. Я к сожалению не разбираюсь.
В фильтрах присутствуют переменные процессов типа Строка, не менее трёх . Чаще всего также присутствует фильтр по наименованию процесса.
Не могу сейчас точно сказать, было ли то же самой на H2, может быть просто пользователь ничего не говорил. Я, работая под администратором, наоборот ощутил ускорение работы от перехода на MSSQL, но у меня нет такого количества заданий :)
Last edit: Artur Nigmatullin 2016-08-18
Может быть помогло бы ограничение количества выводимых экземпляров процессов на странице "Список заданий", как это сделано в "Запущенных процессах"?
Не могли бы Вы реализовать данный фильтр?
Добрый день.
Посмотрел, в нём не зафиксировано каких-то конкретных проблем.
Оно не настолько smart. Оно сбрасывает не все кеши заданий, а только те, на которые повлияла операция, но полностью. Можно подумать об его улучшении до изменений.
Пейджинга в заданиях настоящего не будет, потому что список динамический (с учётом групп пользователей и замещений строится, не в БД).
Т.е. отдать на страницу 10 шт. из 100 можем, но перед отдачей список полный строится будет, так что нет смысла.
Я воспроизвёл у себя проблему (порядка 10 секунд на 120 заданий), думаю можно попрофилировать список заданий на поиск узкого места.
Вообще неплохо было бы добавить на страницу время её загрузки.
При построении списка с выводом значений переменных процессов/заданий каждая переменная для каждого задания подгружается отдельным запросом в БД. Соответственно при построении списка из 30 заданий с 3 переменными ~ 100 запросов уходит в БД только для получения значений переменных При загрузке первый раз это происходит, так как кеш еще не работает. При выполнении задания кеш для пользователя, выполнившего задание так-же сбрасывается (он хранит уже построенный список и из-за изменений его требуется перестроить).
В статистике SQL очень не нравится запрос загрузки переменной (66% времени): select variable0_.ID as ID0_, variable0_.NAME as NAME0_, variable0_.VERSION as
VERSION0_, variable0_.CONVERTER as CONVERTER0_, variable0_.PROCESS_ID as PROCESS12_0_, variable0_.CREATE_DATE as
CREATE6_0_, variable0_.STRINGVALUE as STRINGVA7_0_, variable0_.LONGVALUE as LONGVALUE0_, variable0_.DOUBLEVALUE as
DOUBLEVA9_0_, variable0_.DATEVALUE as DATEVALUE0_, variable0_.BYTES as BYTES0_, variable0_.DISCRIMINATOR as
DISCRIMI1_0_ from BPM_VARIABLE variable0_ where variable0_.PROCESS_ID=? and variable0_.NAME=?
Посмотрите план запроса и какие там есть индексы. Скорее всего вопрос решится созданием индекса.
При работе на H2 проблем не было из-за того, что при работе БД в режиме in-memory колическтво отправляемых запросов не оказывает такого сильного влияния на производительность. При переезде на SQL количество запросов играет раль, так как задержки на передачу по сети намного больше чем в in-memory БД (даже если сама БД находит данные быстрее).
H2 не работала in-memory, БД использовалась как рабочая в течении 2-х лет:
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:${jboss.server.data.dir}/h2/localDB;AUTO_SERVER=TRUE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
Только в прошлом месяце мы перенесли все данные в MSSQL.
а план запроса не смотрели?
Я, честно говоря, не умею этого делать, поэтому неуверен, что правильную информацию Вам сейчас предоставлю (plsql.png).
Кстати, вчера решил проверить, при переносе из H2 в mssql я не выполнил скрипт, создающий индексы (index.sql) , вчера я его провёл. По ощущениям лучше не стало, даже по-моему, стало хуже.
Last edit: Artur Nigmatullin 2016-09-06
Не хотелось бы торопиться с выводами, но сегодня ещё одна странная штука произошла. Решил перезагрузить комп с приложением - автоматом запустился check disk, похоже словил какие то ошибки на диске.. после загрузки runa стала работать значительно шустрее. Но пока не под нагрузкой, пользователи ещё не подошли. Пока наблюдаю. Возможно все же дело было в индексах
Last edit: Artur Nigmatullin 2016-09-06
Оставлять БД без индексов это жестоко. При росте размеров она и винты все убъет постоянным чтением и самой ей будет плохо перелопачивать такой объем данных.
а знаете. что самое странное.. я сверил в dbForge рабочую базу mssql и базу, которую руна автоматически создает если база пуста, так вот во вновь созданной автоматически mssql базе нет тех индексов которые я накатил из скрипта выше.. а скрипт я этот получил при анализе таблиц рабочей базы на H2 ..
Индексы создаются через hibernate и недолжны зависеть от БД. Где то должна быть ошибка - у нас есть инсталляции на MS SQL и там вроде таких проблем не было.
PS. Какие изменения после накатывания индексов?
В списке заданий полльзователя 160 заданий, применён фильтр, в котором есть переменные из процесса (10 шт.), так же есть фильтрация по наименованию процесса, и группировка по одной из переменных процесса => первая авторизация занимается ~3-5сек, завершение задания и возврат к списку заданий занимает ~20-30сек... Так что, ещё остались вопросы к скорости работы, но стало лучше.
Last edit: Artur Nigmatullin 2016-09-07
Скорость работы с большим списком заданий с несколькими переменными исправится только с исправлением кода - необходимо подружать переменные не по одной, а сразу все одним запросом. Последовательное выполнение запросов к БД занимает много времени.
Запланируем доработку и в будущем исправим.
Можно ещё попробовать 2 вещи:
1) использовать 1 кумулятивный индекс вместо 2 разных:
drop index RUNAWFE.IX_VARIABLE_NAME;
drop index RUNAWFE.FK_VARIABLE_PROCESS;
create index RUNAWFE.IX_VARIABLE_PROCESS_NAME on RUNAWFE.BPM_VARIABLE(PROCESS_ID,NAME);
2) т.к. при выполнении задания время ожидания пользователя включает не только построение списка, но и коммит транзакции, обеспечивающей прохождение точки управления по графу - можно попробовать использовать новый режим с более короткими транзакциями: http://www.runawfe.org/rus/doc/ProcessTransactions#ConfigurableBoundaries
Это улучшит ситуацию если после задания много элементов, на которых транзакция не оканчивается.
Кеширование запроса этого не поможет?
1) При работе на H2 проблем не было. То есть проблема не в получении данных в рамках БД как таковой, а в накладных расходах на выполнение запросов (сетевое взаимодействие). Один большой запрос, пусть даже он выгружает лишние данные намного выгоднее чем много мелких, которые грузят только то что нужно.
2) Это к построению списка заданий не относится, так что без коментария.
Можно попробовать включить кеш hibernate, но это только скрывает проблему и код все равно переписывать.
Нужно просто сделать правильную работу с данными. На момент загрузки переменных мы уже знаем все процессы и названия переменных для которых надо выполнить выгрузку. Один запрос в БД для выгрузки всех этих переменных в рамках процесса загрузки списка заданий будет дешев, сократит время выполнения (меньше deadlock) и т.п. В общем переписать код правильно даёт сплошные бенефиты.
Может быть там есть какие то ограничения, из-а которых такой запрос написать нельзя - но тогда будем думать дальше.
drop index "dbo"."BPM_VARIABLE".IX_VARIABLE_NAME;
drop index "dbo"."BPM_VARIABLE".IX_VARIABLE_PROCESS;
create index IX_VARIABLE_PROCESS_NAME on "dbo"."BPM_VARIABLE"(PROCESS_ID,NAME);