Добрый день, всем. Очень долго выполняются запросы связанные с UpdateQuery, SelectQuery, InsertQuery. Кто-нибудь сталкивался с этим? Какие пути использовали, для нахождения проблемы?
Для анализа запросов есть профайлер в mssql. Запускаете профайлере, делаете запрос из клиентской части. Смотрите какой sql для select получается в профайлере.
Еще может быть, что у вас тормозит обмен по websocket. Надо посмотреть в консоль разработчика в браузере, нет ли там ошибки с подключение к websocket.
И еще creatio требовательна к ресурсам, если вам кажется что все работает медленно, то стоит проанализировать производительность ваших серверов.
Для анализа запросов есть профайлер в mssql. Запускаете профайлере, делаете запрос из клиентской части. Смотрите какой sql для select получается в профайлере.
Еще может быть, что у вас тормозит обмен по websocket. Надо посмотреть в консоль разработчика в браузере, нет ли там ошибки с подключение к websocket.
И еще creatio требовательна к ресурсам, если вам кажется что все работает медленно, то стоит проанализировать производительность ваших серверов.
В profiler смотрел, запросы выполняются за доли миллисекунд.
Websocket работает отлично.
Запросы выполняются долго в момент переключения состояния Обращения, вот что заметил. Пока не отлаживал сам процесс перехода состояний, но может уже кто-то сталкивался с этим.
Вероятно, что в системе есть бизнес процесс, который срабатывает по сигналу и работает не в фоновом режиме, выполнение которого и приводит к длительному выполнению запросов InsertQuery и UpdateQuery.
Здравствуйте! Столкнулись с такой проблемой как создание раздела.
При попытке создания раздела через "мастер разделов", мигом проходит "Сохранение слиентских схем", бодро начинается этам "Сохранение схем объектов" (судя по network), но потом минут 30-40 может крутится "Сохранение схем объектов", после чего страница закрывается быстро, и когда ты заходишь в конфигуратор, то там есть все нужные объекты для раздела (но иногда требующие одновить структуру БД), но абсолютно нет никаких привязок, например в "SysModule".
Может кто-нибудь подскажет почему настолько долго выполняется (точнее не совсем выполняется) создание раздела в "Мастере разделов".
Есть желание увеличить быстродействие системы. Выполняю запрос по поиску полей таблиц к которым существует много запросов, но на них нет индексов. И одна из таблиц выпадает AccountCommunication [Средства связи Юр. лиц]. Сам объект унаследовал структуру от объекта [Базовое средство связи]. Так вот получается, что в базовом объекте нет индексов на основные поля для поиска, такие как Id,[Position]. Есть какая-то причина отсутствия индексов на этих полях или их можно создать?
И как все-таки будет правильно, добавить индекс на базовый объект или в тот который унаследовал? Или при добавление в унаследованный объект в базовый он добавится автоматически?
Анастасия, с точки зрения БД родительский и дочерний объекты — это 2 разных таблицы. Следовательно, средствами Management Studio можно добавлять в дочернюю таблицу индексы, если в ходе анализа выяснилось, что это может увеличить производительность.
Сомневаюсь, что на Id стоит добавлять индекс, ведь это и так первичный ключ. А на второе — можно попробовать.
Анастасия, с точки зрения БД родительский и дочерний объекты — это 2 разных таблицы. Следовательно, средствами Management Studio можно добавлять в дочернюю таблицу индексы, если в ходе анализа выяснилось, что это может увеличить производительность.
Сомневаюсь, что на Id стоит добавлять индекс, ведь это и так первичный ключ. А на второе — можно попробовать.
Вот и мне не понятно... Индекс уникальный некластеризованый в БД на Id стоит, а приложение показывает, чтот у этого объкта на этом поле нет индекса.
"Астапеева Анастасия" написал:Есть желание увеличить быстродействие системы.
Желание или необходимость? :smile:
"Астапеева Анастасия" написал:Так вот получается, что в базовом объекте нет индексов на основные поля для поиска, такие как Id,[Position].
не думаю что поле Position - подходящая кандидатура для построения индекса (если я правильно понимаю, это порядковый номер в рамках 1 контрагента?)... кардинальность большая. Индексы хорошо строить по колонкам с практически уникальными значениями (опять же, если СУБД потом будет их использовать).
По-идее индекса по Id и AccountID должно быть вполне достаточно.
Индексов побольше налепить конечно никто не мешает, но будет ли достигнута цель - увеличить быстродействие... а то можно и наоборот сделать, индексы это не бесплатное приложение к таблице.
В общем, есть впечатление что не тут копаете, Анастасия... Могу посоветовать книгу, правда на английском... но может и русские версии уже есть: SQL Server 2008 Query Performance Tuning Distilled (2009)
версия СУБД может и немного старовата, но для CRM систем более чем сгодится.
В общем, есть впечатление что не тут копаете, Анастасия... Могу посоветовать книгу, правда на английском... но может и русские версии уже есть: SQL Server 2008 Query Performance Tuning Distilled (2009)
версия СУБД может и немного старовата, но для CRM систем более чем сгодится.
Используется bpm'online sales 7.7 после перехода с Terrasoft, т.е. все данные были перенесены (порядка 6 млн. активностей). По результату Terrasoft отрабатывает быстрее чем bpm'online. При запуске сайта локально на сервере отрабатывает терпимо, при работе на пользовательских машинах иногда данные вообще не отображаются.
Может кто-то может поделится наработками в вопросе увеличения быстродействия bpm'online on-site: где/как искать проблему, как/что оптимизировать.
Здравствуйте.
Не совсем корректно сравнивать быстродействие BPM'online и Terrasoft 3.x. Эти систему имеют абсолютно разную архитектуру. Terrasoft 3.x - это классическая 2-звенная (клиент-сервер) система. BPM'online - 3-звенная (клиент-сервер базы данных-сервер приложения). Если время отклика системы значительно отличается на сервере и на клиентской машине, тогда стоит обратить внимание на сетевую составляющую (стабильность, ширина канала, особенно если это Wi-Fi), также нужно обеспечить достаточные ресурсы клиентской машины (часть кода выполняется, именно, на пользовательском ПК). Также рекомендую в connectionstrings.config в строке подключения к Redis-серверу не использовать в качестве адреса localhost или 127.0.0.1 (указать сетевое имя или реальный IP-адрес). В противном случае игнорируются параметры, отвечающие за многопоточность подключения к Redis. Это параметры maxReadPoolSize=; maxWritePoolSize= (находятся в том же файле в той же строке). По умолчанию равны – 25. Желательно устанавливать по количеству пользователей *10.
Олег, а вы в браузере посмотрите сколько запросов идет и как долго они выполняются. Таким образом сможете выявить где тормозит и падает.
Например, в версии 7.2 по умолчанию стоит таймаут в 30 секунд на запрос. В результате любые запросы более менее тяжелые могут отвалиться, и при этом останется висеть лоадер, либо просто ничего не произойдет. Самый простой вариант, руками поменять таймаут на больший. И как показывает практика, больше времени уходит на обработку уже на серверной стороне.
Добрый день! В нашей компании встал вопрос с быстродействием системы. В частности менеджеры в региональных офисах стали жаловаться на долгое открытие разделов и карточек в системе. Для эксперимента были сняты трейсы через Profiler. На трейсах были обнаружены непонятные пары запросов: Audit Login и Audit Logout, постоянно отправляемые на сервер. Кроме того, с помощью сниффера, получили странную картину: в определённые моменты времени и сервер и клиент одновременнно простаивают. В связи спроблемой с быстродействием хотелось бы больше понимать механизм работы системы. Можно ли получить больше информации по этому вопросу?
Здравствуйте.
В стандартной конфигурации запросов вида "Audit Login", "Audit Logout" нет. Вероятнее всего, что это либо проектная доработка, либо внесены изменения в конфигурацию с Вашей стороны. Что касается быстродействия, то можно попробовать перестроить индексы базы данных путём запуска "хранимки" sp_reindex_all_tables (скрипт для её создания прикрепил). Запускать нужно в нерабочее время и предварительно ОБЯЗАТЕЛЬНО создать резервную копию базы данных.
Вопрос быстродействия зависит от нескольких факторов – быстродействие ресурса, локальной сети, интернет-соединения и т.д. Заявленное время открытия карточки для версии 5.3 – 2-3 секунды. В 5.2 это немного медленнее, в 5.4 – немного быстрее.
Для того, чтобы проанализировать, на каком этапе теряется производительность, следует провести проверку быстродействия BPMonline.
Вам понадобится:
Google Chrome с установленным компонентом Инструмент разработчика (как правило, установлен по умолчанию).
Как получить детализированную информацию о скорости загрузки отдельной страницы:
1. Откройте необходимую страницу (например, страницу карточки контакт) и дождитесь ее полной загрузки. После этого активируйте инструменты разработчика:
2. Откройте в инструментах разработчика консоль:
3. Вставьте в консоль скрипт (ниже) и нажмите Enter.
(function CheckPerformance(){ if(typeof PageContainer_HtmlMainPage ==='object'){ var mainPageWindow = PageContainer_HtmlMainPage.getWin(); } var targetWindow = mainPageWindow || window; var manager = targetWindow.Terrasoft.PerformanceCounterManager;
manager.getProfileInfo(); var performance = targetWindow.performance|| targetWindow.mozPerformance||
targetWindow.msPerformance|| targetWindow.webkitPerformance; var timing = performance.timing; var navigationStart = timing['navigationStart']; var responseStart = timing['responseStart']; var responseEnd = timing['responseEnd']; var loadEventEnd = timing['loadEventEnd']; var onReadyEnd = manager.getCounter('onReady').finishTime; var networkTime = timing['responseEnd']- timing['responseStart']; var serverTime = responseStart - navigationStart; var parseJsTime = loadEventEnd - responseEnd; var execJsTime = onReadyEnd - loadEventEnd; var fullTime = serverTime + networkTime + parseJsTime + execJsTime; var output ='Передача запроса + Обработка на сервере: '+ serverTime +'\nПрием ответа: '+ networkTime +'\nПарсинг JavaScript: '+ parseJsTime + '\nВыполнение JavaScript:'+ execJsTime +'\nОбщее время: '+ fullTime; return output; })();
4. После того, как скрипт выполнится, в консоли внизу появится результат выполнения скрипта:
5. Кроме того, следует произвести тестирование скорости обращения к серверу по следующей ссылке: http://speed.bpmonline.com/
По результатам проверки можно определить, на каком этапе теряется производительность, и устранить узкие места.
Также хочу обратить Ваше внимание, что если на основной конфигурации ведется разработка (в частности, публикация схем) в момент, когда пользователи работают, это может сильно сказываться на производительности. Это связано с архитектурой – для мгновенного применения изменений необходим перезапуск сайта, который и происходит в автоматическом режиме. Это занимает некоторое время.
Это справедливо для версий 5.3 и новее. Для версии 5.2 IIS автоматически не перезапускается, и при интенсивной разработке по завершении доработок в конфигурации имеет смысл перезапустить его вручную.
Павел, уточните, пожалуйста, какая у Вас версия и какой браузер используется?
Очень похоже, что компонент таймера загрузки (targetWindow.Terrasoft.PerformanceCounterManager), к которому мы обращаемся в скрипте, не существует либо недоступен.
А что могут означать отрицательные значения в результате:
"Обработка на сервере: 644
Сеть: 14
Парсинг JavaScript: 243
Выполнение JavaScript:-5437
Общее время: -4536"
Такое иногда бывает.
Если в результатах выполнения скрипта существуют отрицательные значение, то эти данные не корректны. В таком случае необходимо обновить страницу (F5) и выполнить скрипт повторно.
Также, есть замечательный инструмент, который дает более подробную картину происходящего - это Fiddler:
1. Установить Fiddler http://www.getfiddler.com/dl/Fiddler2Setup.exe
2. Запустить.
3. Включить опцию дешифровки https запроса.
Меню Tools->Fiddler Options.
В появившемся окне выбрать вкладку HTTPS и установить флажок “Decrypt HTTPS traffic”, после чего нажать кнопку “OK”. На все вопросы отвечать “Yes”
4. Перед тем как профайлить нужные действия, необходимо очистить список сессий в Fiddler.
5. Выполнить действия, которые необходимо запрофайлить. Сценарий ниже.
6. Сохранить сессии в файл. Меню File->Save->All Sessions.
Это статья относится к 5.Х, а в нынешней 7.Х движок пользовательского интерфейса полностью другой. Но совет Арсения по поводу Fiddler стал ещё актуальнее, поскольку много операций теперь вынесено на клиентскую сторону и обмен браузера данными с сервером стал доступнее для анализа.
Доброго времени суток, посетители Terrasoft Community!
Сегодня хочу с Вами поделиться информацией о том, как в случае обнаружения проблем с быстродействием BPMonline On-Demand выявить источник проблемы.
Так как физически сервера BPMonline хостятся в датацентре, то серверное оборудование в этом случае полностью удовлетворяет рекомендуемым требованиям к системе. Поэтому чаще всего в подобных случаях проблема заключается либо в пользовательских ПК, либо же в каналах связи пользователь-датацентр.
В первую очередь предлагаю ознакомиться с аппаратными требованиями к пользовательским ПК для комфортной работы с приложением. Предоставляю вырезку из руководства:
Как мы можем видеть, требования довольно невысоки и практически любой современный ПК с лихвой покрывает эти требования. Более примечательным является требования к каналу связи, а именно то, что для комфортной работы в BPMonline ширина канала должна составлять 512 Кб/сек на пользователя системы. Таким образом, если одновременно с BPMonline работает 5 пользователей из одной локальной сети, ширина канала интернет_шлюз_этой_ сети - сервер должна быть 512*5=2,5 Мб/сек.
Теперь о том, как можно выявить источник проблемы в том случае, если Ваш провайдер регламентирует необходимую скорость соединения, но на практике Вы ее не получаете.
В первую очередь рекомендую Вам воспользоваться сервисом тестирования скорости, который доступен на нашем датацентре. Для этого перейдите по ссылке: SpeedTest
На открывшейся странице нажмите на кнопку [Begin test]. В результате Вы получите результат тестирования скорости непосредственно на шлюз датацентра:
Затем попробуйте выполнить трассировку к этому шлюзу. Для этого в интерпретаторе Windows выполните следующие команду: tracert your_web_site - где your_web_site – URL Вашей конфигурации.
В результате Вы сможете просмотреть время отклика от каждого из шлюзов, которые проходит пакет до попадения на гейт BPMonline.
Зачастую полученной информации должно быть достаточно для анализа источника проблемы. Например, если в результате трассировки Вы заметите, что на каком-то из шлюзов происходит значительное проседание времени отклика, то это сразу дает понять, что проблема у провайдера именно на этом узле и можно попробовать обсудить с ним построение маршрута через другой шлюз.
Также в том случае, если технических специалистов, которые смогут получить аналитику согласно этой информации, у Вас в штате нет, то результаты выполнения этих двух простых действий Вы можете направлять в департамент технической поддержки компании Terrasoft по email
Надеюсь, что эта информация будет полезна!
_______________________
Симоненко Владислав
и.о. Руководителя CSM
Группа компаний Terrasoft
Владислав,
как человек чуть-чуть разбирающийся в сетях, хочу сказать, что время отклика от маршрутизаторов, к сожалению, ничего не скажет о скорости работы 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
Павел, спасибо за ответ! Разрешение этой проблемы перевели на данный момент полностью на нашего специалиста техподдержки, поэтому свой вопрос снимаю.
Вопрос: есть ли какая-то объективная причина того, что в БД террасофта ни в одной таблице абсолютно не используются кластерные индексы?
У нас система еле шевелится, при том что очень мощный сервер БД, всего около 150 пользователей, таблицы не сказать что очень огромные (десятки-сотни тыс. записей)... кроме таблиц логов (миллионы-десятки миллионов записей) :)
В общем производительность очень низкая.
В рамках нашего проекта вопрос построения индексов либо не был запланирован вообще либо был проигнорирован... Единственные индексы, которые построены - некластерные индексы по внешним ключам и по первичному ключу.
Здравствуйте,
Так сложилось исторически, что для для MSSQL 2000 в общем случае некластерный индекс является оптимальным, так как в Terraosft 3.X для первичных ключей и внешних ключей используются GUID. В этом случае, если включить кластерные индексы, они будут постоянно перестраиваться, т.к. при вставке записей мы всегда получаем случайное значение GUID и для сохранения упорядоченного вида, новую запись нужно вставить в середину индекса.
Для MSSQL 2008, при использовании последовательных GUID, кластерный индекс будет более производительным. В новых версиях мы проанализируем возможность использования таких индексов для MSSQL 2008.
А как на счет использования "разреженных" индексов, в которых FillFactor < 100 (например 60-80)?
Или использование NEWSEQUENTIALID() вместо NEWID()?
Или введения кластерного индекса не связанного с первичным ключем (например, введение поля типа BigInt с автоинкрементом, либо выделение группы полей по которым возможно построить уникальный индекс, например для контрагента - дата создания, наименование, + может быть ИНН, ОГРН)?
Не проводились ли исследования в этой области? Перед тем как начать самому исследование, хотелось бы услышать какие-то рекомендации, наработки, если таковые имеются.
Дело в том что производительность запросов к БД - действительно "больной" вопрос - тут же блокировка таблиц, которая приводит к возникновению дедлоков в случае "тяжелых" запросов, что отчасти на мой взгляд связано с высокой степенью нормализации и недостаточной индексированностью таблиц, т.к. некластерных индексов по внешним ключам явно нехватает...
Тут же возможно возникнут вопросы по сбору статистики для полей как входящих в индексы так и не входящих в них.
Здравствуйте,
1) Генерация самих GUID в Terrasoft 3.X происходит на уровне приложения (используется внутренний генератор Connector.GenGUID()), это дает возможность использовать значения идентификаторов, до их фактической вставки в таблицу, для того что бы использовать последовательную генерацию идентификаторов, необходимо править бинарные файлы, и менять логику построения на генерацию последовательных идентификаторов.
2) Если Вы имеете в виду, замену uniqueidentifier на BigInt, в Terrasoft в качестве первичных ключей, то боюсь Вас разочаровать, многие вещи в конфигурации заточены под использования типа GUID.
В качестве оптимизации вы можете построить группы полей, по которым чаще всего проводиться фильтрация/поиск, и создать кластерный индекс, это действительно может повысить производительность
Последовательные GUID в нашем случае также противоречат репликации – т.к. ключи могут повторяться.
"Яворский Алексей" написал: Яворский Алексей 2 апреля 2012 – 15:48
Здравствуйте,
Так сложилось исторически, что для для MSSQL 2000 в общем случае некластерный индекс является оптимальным, так как в Terraosft 3.X для первичных ключей и внешних ключей используются GUID. В этом случае, если включить кластерные индексы, они будут постоянно перестраиваться, т.к. при вставке записей мы всегда получаем случайное значение GUID и для сохранения упорядоченного вида, новую запись нужно вставить в середину индекса.
Тоесть Вы хотите сказать, что Table Scan будет быстрее работать на наблице в 50к записей, чем Clustered Index Scan???
И что RID Lookup работает быстрее, чем Key lookup при использовании индексов???
И таблица с Identity колонкой и кластерным индексом по ней и Nonclustered Primary Key будет работать медленней, чем таблица без кластерного идекса???
Универсальное решение тяжело найти, с учетом того что система работает и под FB и Oracle. Не всегда большое кол-во индексов способствует повышению производительности, иногда производительность резко падает из-за переизбытка индексов. Если вы используете MS SQL 2008, то в нем есть хороший инструмент под названием "Мониторинг ресурсов". Он Вам покажет что происходит с диком, процессором и какие тяжелые запросы. На комьюнити выкладывались так же запросы по рекомендациям использования индексов (какие лишниеи каких не хватает). Так же не забывайте каждый день (точнее ночь) перестраивать индексы, чистить кэш (SQL-ный) и собирать статистику.
Евгений, я знаю, что избыток индексов - тоже плохо, я также знаю, что GUID в качестве кластерного индекса тоже плохо, т.к. он быстро фрагментируется.
Я также понимаю, что GUIDы удобнее для разработчиков.
Про мониторинг ресурсов, профайлер, чистку кэша, обновление статистик и др тоже хорошо знаю.
В оптимизации запросов тоже не новичок...
Если вы мне покажете хоть один(!) запрос из нескольких таблиц где записей больше 100 и он будет работать быстрее без кластерных индексов (конечно не по гуиду) я успокоюсь :smile:
Михаил, я не в коем случае не хотел Вас уличить в некомпетентности. Просто я сейчас поддерживаю две крупные базы, каждая из которых примерно 60 Гб. Одна на Oracle, вторая на MS SQL 2008R2. Ни на одной нет кластерных индексов, это не заслуга, просто так исторически сложилось. Сервера работаю в штатном режиме и не особо напрягаются (я не имею ввиду те ситуации когда процесятся OLAP кубы :lol:, но это не часто и не долго). Так вот, основные тормоза идут на конечных рабочих местах при открытии разделов и экранных форм, т.к. ОЧЕНЬ много логики и ОЧЕНЬ много полей, что очень сильно замедляет билдинг и рендеринг клиентского приложения в целом.
"Домброва Михаил" написал:Если вы мне покажете хоть один(!) запрос из нескольких таблиц где записей больше 100 и он будет работать быстрее без кластерных индексов (конечно не по гуиду) я успокоюсь
Такого сравнения не делал. То что он буде работать не медленнее - это точно, но пока обхожусь без него.
Кто знает, может этот момент уже близок, и нужно обязательно переходить на кластерный индекс...
Некоторые собранные мысли, идеи по поводу быстродействия системы Terrasoft CRM
Много чего я взял из тем на форуме и из ответов службы поддержки Террасофт, когда искал как ускорить работу CRM. Возможно, кому-то эта информация будет полезна.
Лабьяк Олег Игоревич пишет:
На быстродействие системы может влиять довольно много параметров. В первую очередь сервер и клиентские места должны удовлетворять аппаратным и программным требованиям для использования программы Terrasoft. Они описаны в документе "Руководство администратора", который поставляется вместе с программой. Также быстродействие зависит от размера базы данных и количества активных подключений к серверу БД.
Проверьте также, включено ли в Вашей базе данных кеширование (для этого необходимо установить значение 1 в колонке UseCache таблицы tbl_DatabaseInfo). Если включена данная опция, память под конкретный экземпляр объекта выделяется только один раз при его создании. При последующих обращениях эти объекты берутся из кеша.
Ещё одна возможная причина - реализация некоторого функционала при открытии раздела. Проверьте профайлером, не выполняются ли в это время запросы, напрямую не связанные с разделом, таблицей tbl_Service и напоминаниями. Очень может нагружать систему использование вызова Services.GetNewItemByUSI(...), особенно в циклах (в результате экземпляр объекта не подтягивается из кеша, а каждый раз создаётся новый экземпляр). Необходимо по возможности этого избегать, используя для получения экземпляров объекта функцию GetSingleItemByCode.
Михайлюк Юра пишет:
Від себе можу додати, я помітив, що продуктивність залежить від кількості активних (відкритих датасетів). Особливо коли вони знаходяться в режимі редагування. Террасофт рекомендує в деяких випадках вимикати реагування на події і після редагування записів вмикати(Dataset.DisableEvents()/Dataset.EnableEvents()).
Мені в одній із карточок реально вдалося підвищити швидкість відображення разів в 10 лише відключивши у відкритих датасетах (з яких дані лише беруться) режим редагування.
Ще один фактор який мені порадили, по мінімуму прив'язувати таблиці до системи перевірки прав доступу. Можете перевірити на свойому клієнті під Адміністратором (мабуть блок "Адміністрування по записам" або "Групи таблиць" не активний) система завантажується і працює в 1,5 рази швидше.
Осауленко Александр пишет:
Необходимо определиться, клиент тормозит или сервер. Я бы сначала посмотрел на запросы от клиента к серверу (профайлер от sql server).
В этой записи в моем блоге я привожу пример как можно проанализировать время выполнения запросов и работы клиентской части CRM с помощью SQL Profiler:
Тема: Анализ быстродействия CRM с помощью SQL Profiler http://community.terrasoft.ua/blogs/6030
Служба поддержки Террасофт пишет:
Для увеличения быстродействия открытия окон, при их разработке необходимо учитывать следующее:
1. Минимизировать логику в обработчиках событий OnPrepare, OnShow.
2. Не загромождать окна лишними контролами.
3. Использовать минимальную вложенность контролов.
4. Группировать контролы в отдельные фреймы, в зависимости от их смыслового назначения. Использовать центрирование контролов в фреймах по правому либо по левому краю.
5. Уменьшить использование подсветки записей в реестре. Использование подсветки значительно замедляет работу системы.
6. Отображать минимальное количество колонок в реестре, остальные скрывать.
Значительном шагом на пути улучшения быстродействия системы является ограничение записей, отображаемых в реестре записей каждого раздела. При уменьшении объема отображаемой информации снижается объем используемой
оперативной памяти компьютера, а также уменьшается нагрузка на сетевой трафик – что приводит к значительному улучшению в быстродействии программы.
Из личного примера: нужно было ускорить время открытия карточки редактирования задачи. После ранее внесенных изменений с моей стороны она открывалась секунд 5-6. Причину я нашел: подключал слишком громоздкие скрипты (например скрипт окна грида документов - wnd_DocumentsGridArea). Почистил подключаемые скрипты, перенес некоторые функции из подключенных скриптов в сам скрипт окна редактирования задачи. И как результат - окно начало открываться 1-2 секунды. Да, это была моя ошибка, но таким образом я узнал, что количество подключаемых скриптов тоже может влиять на быстродействие.
По этому поводу:
Служба поддержки Террасофт пишет:
Чем больше используется подключенных скриптов, тем больше времени затрачивается на инициализацию, следовательно уменьшается быстродействие работы системы.
Рекомендуется подключать только базовые скрипты. При наличии маленьких скриптов, лучше их не подключать, а включить прописанные в них функции непосредственно в код основного скрипта.
Также, избегайте зацикливания при подключении скриптов.
Как отключить скрипт из основного скрипта, таким образом исключив затраты на его инициализацию во время загрузки CRM, я описал в следующем посте:
Тема: Обращение к переменным и методам скрипта http://community.terrasoft.ua/forum/topic/6036
По этому поводу я задал следующий вопрос в Службу поддержки Terrasoft:
Кошкаров Андрей, задавая вопрос, пишет:
Подскажите какие плюсы/минусы использования скриптов и их методов этими способами, как может это повлиять на быстродействие системы:
1. Подключать нужный скрипт в текущий скрипт и обращаться к функциям из подключенного скрипта напрямую, например:
ExportAccountToClient(AccountID);
Минус: это что всегда при инициализации основного скрипта инициализируется и подключенный скрипт, который может быть довольно ресурсоемким.
2. Вызывать метод скрипта через получение этого скрипта из кэша или из БД (если не закеширован). Например:
var scrGeneral1CUtils = Services.GetSingleItemByUSI('scr_General1CUtils');
scrGeneral1CUtils.ScriptControl.Run('ExportAccountToClient', AccountID);
Плюс: что мы избегаем обязательной инициализации дополнительных скриптов при инициализации основного скрипта.
Ответ был полезным для меня:
Служба поддержки Террасофт пишет:
В общем, Вы описали один из методов оптимизации, который мы использовали при написании базовой конфигурации 3.3.2.
Из scr_Main было убрано явное и косвенное использование scr_UserReportCommon, в результате 3.3.2 стало запускаться почти в 2 раза быстрее, чем 3.3.1.
Из минусов второго варианта на ум приходит только то что в главном скрипте нельзя будет прямо использовать глобальные переменные подчиненного скрипта. Но если вспомнить про инкапсуляцию данных, это становится весьма незначительным минусом.
Так же, при использовании второго подхода мы бы посоветовали локально кешировать (в главном скрипте сохранять в переменной полученный экземпляр подчиненного скрипта) сервис полученный через GetSingleItemByUSI, т.к. если вызвать GetSingleItemByUSI второй раз, то и во второй раз будет проведена
полная инициализация подчиненного скрипта (и возможно всех его uses тоже, этот вопрос требует исследования).
Так же, для вызова методов подчиненного скрипта можно использовать не конструкцию вида:
На сколько я знаю, сравнение этих методов не проводилось. Но исторически сложилось, что мы используем второй вариант.
В целом, этот механизм стоит применять когда создается слабая связь 2 больших функционалов. Чтобы зависимый функционал инициализировался только когда нужно, а не когда инициализируется главный.
Из личного опыта:
Кошкаров Андрей пишет:
Благодаря использованию конструкций кода, вместо подключения скриптов к главному скрипту (пример):
function GetIsOLAPControlIstalled_(){ if(!Assigned(Main.scrOLAPUtils)){
Main.scrOLAPUtils= Services.GetSingleItemByUSI('scr_OLAPUtils'); } return Main.scrOLAPUtils.ScriptControl.CodeObject.GetIsOLAPControlIstalled(); }
получилось ускорить время загрузки CRM с активным разделом "Контрагенты".
Показатели были получены при запуске на тестовом компьютере (процессор Intel Celeron 600 MHz, 256 Мб ОЗУ):
До:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
1.581 | 196.898 | 198.409
После:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
1.274 | 123.109 | 124.329
Итого общее время было уменьшено с приблизительно 3 мин. 20 сек до 2 мин. 4 сек., благодаря уменьшению времени на выполнение операций, выполняемых клиентской частью CRM.
ускорить время открытия карточки редактирования записи контрагента:
До:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
0.019 | 18.848 | 18.863
После:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
0.021 | 6.463 | 6.481
Итого общее время было уменьшено с приблизительно 19 сек до 6.5 сек.
ускорить время инициализации раздела "Задачи":
До:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
2.875 | 27.772 | 30.620
После:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
0.077 | 18.441 | 18.509
Итого общее время было уменьшено с приблизительно 28 сек до 18.5 сек.
ускорить время инициализации карточки редактирования задачи:
До:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
0.073 | 21.738 | 21.804
После:
Серверная часть (сек)| Клиентская часть (сек) | Общее время (сек)
0.039 | 4.087 | 4.122
Итого общее время было уменьшено с приблизительно 22 сек до 4 сек.
Кому то будет полезна информация о процессе инициализации окон в разделе и в окне редактирования (последовательность, наиболее ресурсоемкие операции):
Служба поддержки Террасофт пишет:
Процесс инициализации окон в разделе:
1. Десериализация – восстановление сохраненных объектов. Если раздел отображается впервые – происходит считывание данных из БД. Если раздел уже отображался – происходит считывание данных из Cache. В том случае, если системные характеристики компьютера достаточно низкие данная процедура будет происходит сравнительно медленно.
2. Инициализация групп, основного реестра, глобальных переменных, ссылок на наборы данных и открытие набора данных групп.
Отправной точкой для отображения данных является открытие набора данных групп с позиционированием на корневой группе (function OpenGroupsDataset()).
3. Вызов метода Show() для каждого элемента раздела.
4. Вызов метода Prepare() для каждого элемента раздела.
5. Фильтрация реестра записей.
6. Фильтрация текущего представления
7. Заполнение реестра данными
8. Refresh активной детали.
Процесс инициализации карточки редактирования:
1. Десериализация.
2. Вызов метода Show() окна.
3. Вызов метода Prepare() окна.
Наиболее ресурсоемкие операции –десериализация, прорисовка контролов, подтягивание данных.
С функциями, используемыми при инициализации Вы можете ознакомиться в SDK.
Как снизить время первоначального открытия разделов. Несколько видоизменил ответ от Раловец Ольги, добавив возврат в первоначально загружаемый раздел. Также внесены были замечания от других пользователей:
Раловец Ольга пишет:
Пример реализации из проекта.
function wnd_MainOnShow(Window){
Self.BeginUpdate(); var WspCodesArray = Main.UserSettingsWindow.Attributes('WorkspacesForCaching').split(' '); for(var i in WspCodesArray){ var WorkspaceWindowCode = WspCodesArray[i]; if(IsEmptyValue(WorkspaceWindowCode)){ continue; } var WorkspaceWindow = GetWorkspaceByUSI(WorkspaceWindowCode);
wndWorkspace.Window= WorkspaceWindow; var EditWindowUSI =''; if(Assigned(WorkspaceWindow.ComponentsByName('wndGridData'))){
EditWindowUSI =
WorkspaceWindow.ComponentsByName('wndGridData').Window.Attributes('EditWindowUSI'); } if(IsEmptyValue(EditWindowUSI)){ continue; } var Attrs = GetNewDictionary();
AddRequiredValuesToDictionary(Attrs, GUID_NULL,false,true); var EditWindow = ShowEditWindowEx(EditWindowUSI, Attrs, System.EmptyValue,true,true);
EditWindow.Close(); }
Self.EndUpdate(); }
В данном случае требовалось кэшировать при запуске системы разделы, отмеченные пользователем в настройках, и их карточки редактирования. Вместо строчки
var WspCodesArray = Main.UserSettingsWindow.Attributes('WorkspacesForCaching').split(' ');
можно явно указать нужные разделы, задав массив WspCodesArray, элементами которого являются коды главных окон этих разделов, например, 'wnd_ContactsWorkspace'. Если карточки редактирования Вас не интересуют, то все сведется к
function wnd_MainOnShow(Window){ //предварительная инициализация разделов
Self.BeginUpdate(); var OriginalWorkspaceWindow = wndWorkspace.Window; var WspCodesArray =new Array('wnd_AccountsWorkspace', 'wnd_ContactsWorkspace','wnd_TasksWorkspace', 'wnd_OpportunitiesWorkspace','wnd_ContractsWorkspace', 'wnd_DocumentsWorkspace','wnd_InvoicesWorkspace', 'wnd_MailWorkspace'); for(var i in WspCodesArray){ var WorkspaceWindowCode = WspCodesArray[i]; if(IsEmptyValue(WorkspaceWindowCode)){ continue; } var WorkspaceWindow = GetWorkspaceByUSI(WorkspaceWindowCode);
wndWorkspace.Window= WorkspaceWindow; }
wndWorkspace.Window= OriginalWorkspaceWindow;
Self.EndUpdate(); }
Данная функция описана в скрипте scr_Main. Проект был реализован на базе версии 3.2.1.
Комментарий от партнера вендору: более чем ценная информация. для каждого из нас. не секрет, что темпы развития продуктов ТС опережают возможности документаторов и техподдержки ТС. Опережают они и наши возможности. Намного опережают. В ходе работы часто сталкиваемся с ситуацией когда надо перелопатить "единого слова ради тысячи тонн словесной руды" (форумы на Сообществе, документация к продуктам) и...все равно решения нет. Очень нужна публикация такого рода обобщенных наблюдений. в том числе от техподдержки ТС, когда вы, коллеги, отвечая по запросам, находите ответ или решение, не задокументированное ранее. Спасибо.
А еще ...
В базовой функции RefreshDetails все вставляют толпу if'ов и условия там идут вида: pgDetails.ActivePage.Name == pgMyDetail.Name
Для меня до сих пор, кстати, загадка зачем берут именно свойство объекта, а не строку )
это раз. а два - это ifы необходимо заменить на switch. В данном контексте switch работает быстрее. Конечно же это просто капля по сравнению со всем другим, но все-таки ;-)
В данный момент, в процессе переключения между разделами/деталями/представлениями и другими элементами требующими подгрузки данных из БД у нас возникает "небольшая пауза". Она обозначает, что система формирует запрос и получает новую информацию в реестр (всю информацию из БД загружать не выгодно, ее может быть слишком много).
Такой эффект, заставляет думать нас о том, что система работает медленно и такое убеждение складывается обычно у неопытных пользователей. Они не понимают принцип работы. С другой стороны, зачем же создавать иллюзию медленной работы, если можно заменить ее принятыми в мире ИТ способами.
"Лаг" загрузки заменить на уже принятую всеми полосу загрузки или какую-нибудь приятную анимацию в области представления загружающихся данных.
В тоже время, убрав общее блокирование интерфейса (в данный момент, нельзя работать с карточками и объектами в момент загрузки новых данных или обновления имеющихся).
Можно ли увидеть в новой версии доработку этой эстетической стороны интерфейса?
"Лаг" весьма актуальный. Часто приходится сталкиваться с негативными отзывами о Terrasoft именно по причине указанного "лага". Было бы отлично, если данная проблема была решена.
