Добрый день, подскажите, существует ли функционал или инструменты для диагностики и оценки производительности приложения?

Какие-нибудь дашборды или графики?

Спасибо.

Нравится

4 комментария
Лучший ответ

Добрый день.

На текущий момент подобный функционал отсутствует в приложении Creatio. 

Предположительно, через несколько версий, появится нечто подобное.

Частично - в Process log есть поле с продолжительностью работы бизнес-процессов. По нему можно отслеживать, какие элементы тормозят больше всего. Но надо учитывать, что часть элементов - это взаимодействие с пользователем

Добрый день.

На текущий момент подобный функционал отсутствует в приложении Creatio. 

Предположительно, через несколько версий, появится нечто подобное.

Владимир Соколов,

Спасибо.

Также, если сайт развернут on-site, то можно с помощью инструментов отладки запросов СУБД анализировать длительность выполнения запросов. Например, для MS SQL это SQL Profiler.

Показать все комментарии

Для получения sql-запроса из 3246 объектов уходит 11 секунд. В объекте (Account) 107 колонок, которые перебирает O(n^2) алгоритм. Итого получаем:

3246 * 107 * 107 = 37 миллионов итераций, что просто ужасно долго. Учитывая, как часто используется этот метод (каждый Save()), большая просьба подумать над алгоритмом и переписать его в будущих версиях :)

 

Изображение удалено.

3 комментария

Не совсем понимаю, зачем Вам для 3246 объектов (или 3246 раз для Account) вызывать эту функцию. Что Вы делаете со всеми полями всех объектов, добавляете в параметры?

Не поможет ли тут какое-то кеширование?

Зверев Александр,



Напоминаю, эта функция вызывается неявно каждое сохранение в системе. Вы сохраните 100 сущностей - вызовете функцию 100 раз. Налицо глобальная деградация производительности в этом блоке.

Здравствуйте, Алекс!

Передали данное пожелание команде разработки для анализа возможности внесения такой оптимизации в будущих версиях продукта.

Показать все комментарии

Наткнулся на ужасную проблему производительности при создании представления в БД.

Ситуация такая, что в таблице, по которой работает View очень-очень много данных. Но по ключевым полям построены индексы и если делать деталь по самой таблице, то всё ок.

Но мне потребовалась небольшая агрегация данных, я сделал View.

В итоге SELECT * FROM myView WHERE UsrMyId = '' отрабатывает мгновенно, но при создании детали на этом представлении система генерирует какой-то бешеный запрос

exec sp_executesql N'
SELECT
    [myView].[Id] [Id],
 
...мои поля...
    (
SELECT
    COUNT([SubEntryPoint].[Id]) [Count]
FROM
    [dbo].[EntryPoint] [SubEntryPoint] WITH(NOLOCK)
WHERE
    [SubEntryPoint].[EntityId] = [myView].[Id]
    AND [SubEntryPoint].[IsActive] = @P2) [SubEntryPoint]
FROM
    [dbo].[myView] [myView] WITH(NOLOCK)
WHERE
    [myView].[UsrMyId] = @P1
ORDER BY
    [UsrServiceName] ASC OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY',N'@P1 nvarchar(32),@P2 bit',@P1=N'bc1fc0d8f6d98c04b93a8fb1070f4766',@P2=1

который дико бешено тормозит!

Можно ли заставить деталь сделать более простой и очевидный запрос?

Нравится

3 комментария

В подзапросе происходит выборка бизнес-процесов, привязанных к определенным обьектам, которые находяться в стадии выполнения. Скорее всего у вас эта таблица БД имеет очень большое количество записей, т.е. у вас очень много незавершенных бизнес-процессов. Проверьте количество записей в таблице EntryPoint.

Мотков Илья,

Количество записей в таблице EntryPoint равно 0. разумеется мы это проверили.

Вообще, интересно, что когда я развернул  этот запрос без exec sp_executesql и подставил параметры, всё отработало быстро. А вот с процедурой в тысячу раз медленнее.

Алексей, посмотрите планы выполнения ваших запросов. Возможно, что у вас закеширован неоптимальный план выполнения запроса с параметром. 

Показать все комментарии

Добрый день, в настоящее время существуют проблемы с производительностью BpmOnline.
Выражаются в периодических продолжительных паузах. При переходах между вкладками, открытии справочников, сохранении элементов.

Подскажите как можно понять где узкое место?
База, или сервер, или клиент?

Может есть уже готовый кейс по профилированию?

Нравится

2 комментария

Если это база, то можно проанализировать трассировку запросов к базе через SqlProfiler.
Возможно выполняются слишком тяжелые запросы.
Можно проверить также как там память сервера поживает при этом.
Также можно воспользоваться Fiddler'ом.

А можно проверить производительность при помощи консоли браузера: http://www.community.terrasoft.ru/blogs/8480

Показать все комментарии

Добрый день, коллеги.
Столкнулся с жалобами пользователей на производительность ПО Terrasoft CRM (да и сам стал замечать). Чаще всего жалуются на долгое открытие карточек объектов. Так вот, вопрос в чем: пробовал ли кто-нибудь копать в сторону профилирования JScript-кода Terrasoft и подсчета времени какая функция сколько работает?

Нравится

9 комментариев

Есть scr_DebugUtils для тестирования отдельных функций. Также можно пройти процесс открытия в отладке, поставив debugger на OnPrepare и посмотреть, какой шаг долго срабатывает.

Здравствуйте.
Специально для таких целей инструментарий не создавали, но можно воспользоваться, например, той же Visual Studio: http://msdn.microsoft.com/ru-RU/library/dd264908.aspx. Так же желательно определить на каком этапе возникает задержка. Кроме Jscript это может быть и сеть и сервер. Для версии 5.4 на нашем ресурсе есть скрипт, который показывает разбивку по времени (клиент, сеть, сервер) выполнения того или иного действия: http://www.community.terrasoft.ua/blogs/8480. Ещё можно использовать такой инструмент как fiddler.

"Котенко Александр" написал:Для версии 5.4

Автора интересует 3.Х.

"Котенко Александр" написал:Так же желательно определить на каком этапе возникает задержка

Вот мне и нужно понять, где задержка: сервер БД или код.
Можете поподробнее рассказать как можно применять Visual Studio для профилирования JScript кода конфигурации Terrasoft CRM? Или то что вы написали относится исключительно к BPM Online?
У меня используется платформа Terrasoft 3.3.2.

Тут и тут и тут описано. Важно оттуда:

"Лучкив Александр" написал:Часто при разработке конфигурации необходимо ставить точки останова (Breakpoint) в скриптах для пошаговой отладки.

Для этого достаточно написать в скрипте команду:
debugger;

"Пунько Наталия" написал:Активируйте отладчик скриптов, установив ключ реестра JITDebug
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows Script\Settings]
"JITDebug"=dword:00000001
Прикрепленный файл
enabledebugger.rar

"Зверев Александр" написал:Тут и тут и тут описано.

Спасибо конечно, но как отлаживать конфигурацию Terrasoft я знаю. Я не знаю как профилировать код конфигурации и возможно ли это для Terrasoft CRM. Вот это относится только к BPM Online:
"Котенко Александр" написал:Специально для таких целей инструментарий не создавали, но можно воспользоваться, например, той же Visual Studio:
???

См. scr_DebugUtils. Инструменты BPMonline никак не связаны с 3.Х.

Когда-то тоже сталкивался с похожей проблемой.
Сделал некоторые заметки, вот они:
Ускорение работы CRM - тут есть ссылки на другие публикации

Тогда я пошел довольно не простым путем - смотрел где узкое место с помощью SQL Profiler, описал вот здесь:
Анализ быстродействия CRM с помощью SQL Profiler
С помощью этого метода я четко смог увидеть где проблема: на стороне скриптов и компьютера пользователя или на стороне сервера.

Только что добавил запись в блог с описанием разработанного мной функционала для поиска узких мест в выполнении функций:
Анализ времени выполнения скриптов и поиск "узкого" места в функционале

Показать все комментарии

Добрый день!

Можно узнать, почему в версии 3.4 отказались от кластерных индексов на таблицах?
В таких условиях производительность БД будет неуклонно(!) снижатся по мере увиличения количества записей в таблицах.
Я конечно понимаю, что кластерный индекс по GUIDу не лутшее решение из за его быстрой фрагментации, но почему в таком случае не добавить в таблицы identity колонку?
С уважением,
Михаил

Нравится

3 комментария

Здравствуйте.

Уточню данную информацию у коллег из департамента разработки, и сообщу Вам в ближайшее время ответ.

Так и не уточнили?

Здравствуйте, Михаил.

"Домброва Михаил" написал:Можно узнать, почему в версии 3.4 отказались от кластерных индексов на таблицах?

Они не нужны.

"Домброва Михаил" написал:В таких условиях производительность БД будет неуклонно(!) снижатся по мере увиличения количества записей в таблицах.

В условиях, когда остальная окружающая базу среда не меняется.
"Домброва Михаил" написал:
Я конечно понимаю, что кластерный индекс по GUIDу не лутшее решение из за его быстрой фрагментации, но почему в таком случае не добавить в таблицы identity колонку?

А зачем?

Показать все комментарии

Доброго времени суток, посетители Terrasoft Community!

Сегодня хочу с Вами поделиться информацией о том, как в случае обнаружения проблем с быстродействием BPMonline On-Demand выявить источник проблемы.

Так как физически сервера BPMonline хостятся в датацентре, то серверное оборудование в этом случае полностью удовлетворяет рекомендуемым требованиям к системе. Поэтому чаще всего в подобных случаях проблема заключается либо в пользовательских ПК, либо же в каналах связи пользователь-датацентр.

В первую очередь предлагаю ознакомиться с аппаратными требованиями к пользовательским ПК для комфортной работы с приложением. Предоставляю вырезку из руководства:
s

Как мы можем видеть, требования довольно невысоки и практически любой современный ПК с лихвой покрывает эти требования. Более примечательным является требования к каналу связи, а именно то, что для комфортной работы в BPMonline ширина канала должна составлять 512 Кб/сек на пользователя системы. Таким образом, если одновременно с BPMonline работает 5 пользователей из одной локальной сети, ширина канала интернет_шлюз_этой_ сети - сервер должна быть 512*5=2,5 Мб/сек.

Теперь о том, как можно выявить источник проблемы в том случае, если Ваш провайдер регламентирует необходимую скорость соединения, но на практике Вы ее не получаете.

В первую очередь рекомендую Вам воспользоваться сервисом тестирования скорости, который доступен на нашем датацентре. Для этого перейдите по ссылке:
SpeedTest

На открывшейся странице нажмите на кнопку [Begin test]. В результате Вы получите результат тестирования скорости непосредственно на шлюз датацентра:
SpeedTest

Затем попробуйте выполнить трассировку к этому шлюзу. Для этого в интерпретаторе Windows выполните следующие команду:
tracert your_web_site - где your_web_site – URL Вашей конфигурации.
В результате Вы сможете просмотреть время отклика от каждого из шлюзов, которые проходит пакет до попадения на гейт BPMonline.
Tracert

Зачастую полученной информации должно быть достаточно для анализа источника проблемы. Например, если в результате трассировки Вы заметите, что на каком-то из шлюзов происходит значительное проседание времени отклика, то это сразу дает понять, что проблема у провайдера именно на этом узле и можно попробовать обсудить с ним построение маршрута через другой шлюз.

Также в том случае, если технических специалистов, которые смогут получить аналитику согласно этой информации, у Вас в штате нет, то результаты выполнения этих двух простых действий Вы можете направлять в департамент технической поддержки компании Terrasoft по email support@terrasoft.ru

Надеюсь, что эта информация будет полезна!:wink:
_______________________
Симоненко Владислав
и.о. Руководителя CSM
Группа компаний Terrasoft

Нравится

11 комментариев

Владислав,
как человек чуть-чуть разбирающийся в сетях, хочу сказать, что время отклика от маршрутизаторов, к сожалению, ничего не скажет о скорости работы bpmonline SaaS.

Да, но зачастую это дает понять, в каком направлении искать проблему.
Например, у меня на практике был случай, когда при трассировке у клиента на первом же шаге время было более 100 мс. Оказалось, что у клиента были проблемы с роутером, который и вызывал проблемы с быстродействием не только приложения, но и работы в сети Internet в целом, хотя ширина канала вроде-бы удовлетворяла требованиям. Так что как первый способ поиска проблемы я думаю, что все-таки аналитику из описанных шагов получить получится.

Со временем я буду дополнять эту тему более детальной информацией.

Уважаемые коллеги,

Как новый пользователь BPMOnline CRM, хочу добавить комментарий (подчеркиваю, со стороны Пользователя). Первое впечатление - несколько настораживает (если не сказать удручает), замедление со временем скорости открытия новых окон, например, при первичном наполнении справочников. Простая задача - заведение списка необходимых нам стран и городов в этих странах происходила следующим образом:
- Создаю страну
- Создаю город №1 в стране
....
- Создаю город №15 в стране
- Выхожу из системы (т.к. открытие окна занимает около 5 секунд, по сравнению с мгновенным откликом в самом начале)
- Закрываю браузер (т.к. он "съел" около 1Gb памяти)
- Открываю браузер, продолжаю вводить данные и так далее.

Пробовали использовать несколько браузеров (IE, FireFox, Chrome), результат везде один и тот же.
Сейчас провожу простой эксперимент - последовательно открываю и закрываю карточки клиентов (просто на чтение, никаких изменений не вношу). Через 15 карточек браузер (Chrome) использует 218Mb памяти (до открытия первой карточки - 60Mb), скорость открытия карточек замедляется, что видно невооруженным взглядом.
На мой взгляд - это ненормально.

Инсталляция Onsite, Версия 5.2.0.359, SQL2008R2, Сервера приложения и баз данных - новые машины с W2008R2 со всеми апдейтами, с сетью проблем нет (прочие корпоративные приложения работают без проблем с производительностью).

Константин, Ваш запрос переведен в департамент разработки и тестирования.
По результату работ мы с Вами свяжемся, сообщим о решении.

А если при соединении с локально поднятым (время отклика <1мс) тормоза? Куда копать?
Симптомы - на клиенте Google Chrome, после входа и перехода на раздел Контрагенты первый подъем карточки Контрагента при нажатии кнопки Добавить 20 секунд.

Александр, время отклика в данном случае не влияет на работу приложения. Т.к. пакеты ICMP низкоуровневые и они не позволяют объективно оценить загрузку приложения на сревере.

Большая продолжительность открытия карточки при первом ее запуске, связан с построением кешируемых объектов в самой системе. Это время, в частности, может зависеть от производительности серевра и выделенной физической памяти, для сервера приложения.

А замечается ли разница при тех же действиях, производимых на самом сервере?

Константин, к сожалению со стороны сервера приложенния мы не можем непосредственно повлиять на выделение и освобождение памяти браузером. В Chrome, например, все открываемые окна (и ссылки тоже) используют контекст родительской вкладки, причем ресурсы полностью не высвобождаются вплоть до ее закрытия. Это не связано с BPMonline и происходит на любых сайтах, когда одна страница постоянно остается открытой и с нее часто открываются новые окна.
В результате, при длительной работе с BPMonline выделение памяти в Chrome может достигать значительных размеров. С Firefox таких проблем не обнаружено, но при открытии окон некоторые плагины, в частности - Firebug, тоже могут вызывать утечки памяти и существенно увеличивать ее потребление.
Как правило, 218Мб выделенной браузером памяти (при наличии ее порядка 2Гб) не должно влиять на производительность приложения. Попробуйте, пожалуйста, сделать дамп сессий в Fiddler и выслать нам результаты.

Красткая инструкция по настройке Fiddler прикреплена.

"Фильковский Павел" написал:

Александр, время отклика в данном случае не влияет на работу приложения. Т.к. пакеты ICMP низкоуровневые и они не позволяют объективно оценить загрузку приложения на сревере.

Большая продолжительность открытия карточки при первом ее запуске, связан с построением кешируемых объектов в самой системе. Это время, в частности, может зависеть от производительности серевра и выделенной физической памяти, для сервера приложения.

А замечается ли разница при тех же действиях, производимых на самом сервере?

С уважением, Фильковский Павел

Специалист службы поддержки

Группа компаний Terrasoft


Павел, спасибо за ответ! Разрешение этой проблемы перевели на данный момент полностью на нашего специалиста техподдержки, поэтому свой вопрос снимаю.

При переходе на http://speed.bpmonline.com/, перенаправляет на главную страницу http://www.bpmonline.com/

Иван, данным вопросом сейчас занимаются администраторы площадок on-demand.

Сайт восстановлен!

Показать все комментарии
Довгань Андрей пишет:
Конечно же, мы будет оптимизировать и, надеюсь, в скором времени все будут приятно удевлены

Огромный блок данных в каждой странице составляет ViewState. Будет возможность хранить ViewState на сервере?

Нравится

1 комментарий

Добрый день, Виталий!

Спасибо за Ваше замечание. Мы обязательно его проработаем.
Задачу мы планируем разбить на две:

  1. Анализ и оптимизация состава ViewState
  2. Анализ и тестирование хранения ViewState на сервере
Показать все комментарии