1С замеры производительности

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

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

Результат замера производительности представляет собой список ссылок на конкретные строки модуля, с указанием частоты их выполнения и длительности (абсолютного времени выполнения и относительного, в процентах от общего времени выполнения замеряемого участка). Также в списке отмечаются строки кода, исполнявшиеся на клиенте, сервере и строки кода, приводящие к вызову сервера:

Результаты замера можно видеть также непосредственно в окне с исходным текстом модуля. Щелчком мыши на выбранной строке списка можно перейти к тексту модуля, для которого на отдельном поле будет отображено количество вызовов и относительное время выполнения каждой строки:

Результаты замера могут быть отобраны по месту исполнения (клиент, сервер, клиент и сервер), а также отсортированы по любой из колонок, например, по количеству вызовов строки:

Кроме этого, режим замера производительности позволяет производить выборочное суммирование строк замера, для получения суммарных характеристик выполнения некоторых строк:

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

Разработчик может сохранить результаты замера в файл для последующего анализа и сравнения с результатами других замеров.

В статье рассматривается базовая методика анализа проблем производительности в работающей многопользовательской системе при помощи «Центра управления производительностью».
В настоящей статье рассматривается методика анализа производительности и оптимизации реально работающей многопользовательской системы на платформе «1С:Предприятие 8».
Данная методика будет наиболее полезна в следующих случаях:
• Проблемы производительности не локализованы в определенных бизнес-процессах, а «равномерно распределены» по всей функциональности системы. Все (или почти все) пользователи жалуются на недостаточную производительность системы, но не могут назвать одну конкретную операцию, производительность которой их не устраивает. Субъективная оценка формулируется так: «все работает медленно».
• В системе имеются четко локализованные проблемы производительности, которые не воспроизводятся на тестовой базе в однопользовательском режиме. Например, пользователи жалуются на недостаточную производительность документа «РеализацияТоваровУслуг», но при проведении этого документа в нерабочее время и/или на тестовой базе производительность оказывается в норме.
• В системе имеется большое количество хорошо локализованных проблем производительности. Задача заключается в том, чтобы максимально быстро определить, с чего именно следует начинать оптимизацию системы. Необходимо обнаружить источник (или источники) всех имеющихся проблем и найти наиболее узкое место в системе.
• Система запускается в рабочую эксплуатацию после существенного изменения условий работы системы:
o изменилась нагрузка на систему;
o изменилась конфигурация;
o изменилась используемая версия «1С:Предприятия»;
o изменилась используемая СУБД;
o изменилась конфигурация оборудования;
o и т. п.
• На начальном этапе эксплуатации системы ее производительность была признана удовлетворительной, но по мере наполнения информационной базы производительность стала падать.
• Планируется увеличение нагрузки на систему, и необходимо гарантировать отсутствие в системе скрытых проблем, которые могут привести к падению производительности при росте нагрузки.
• Система стабильно работает с удовлетворительной производительностью. Необходимо гарантировать своевременную и точную диагностику проблем производительности в случае их возникновения.
Кроме того, методику рекомендуется использовать при проведении многопользовательского нагрузочного тестирования системы с целью оценки производительности, анализа возникающих проблем и оптимизации системы.
Оценка производительности системы
Оцените текущую производительность системы на основании прикладных критериев. После этого последовательно выполните все нижеследующие рекомендации по шагам. В зависимости от того, как оценивается текущая производительность системы, некоторые шаги могут быть пропущены.
Неудовлетворительная производительность
Критерии:
• Производительность системы не удовлетворяет требованиям бизнес-логики автоматизируемого предприятия на значительной части операций.
• Большая часть пользователей системы жалуется:
o На неприемлемую общую производительность системы.
o Неприемлемую производительность на отдельных операциях.
o Внезапное ухудшение производительности.
o Частое возникновение ошибок:
 «Lock request time out period exceeded».
 «Превышено максимальное время ожидания предоставления блокировки».
 «Transaction was deadlocked on lock resources with another process and has been chosen as deadlock victim».
 «Конфликт блокировок при выполнении транзакции».
Недостаточная производительность
Наблюдаются аналогичные симптомы, но возникающие реже либо проявляющиеся не в такой серьезной форме.
Удовлетворительная производительность
Пользователи системы практически не жалуются на проблемы производительности. Однако нет уверенности в том, что система работает оптимально. Возможно, есть скрытые проблемы производительности, которые пока не проявились в явном виде.
Регламентные операции
В любом случае необходимо убедиться в том, что все необходимые регламентные операции правильно запланированы и своевременно выполняются.
Если производительность системы признана неудовлетворительной или недостаточной, имеет смысл однократно выполнить все рекомендуемые регламентные операции и после этого повторно оценить производительность системы.
Рекомендации по выполнению регламентных операций для систем, работающих с использованием MS SQL Server (статья в базе знаний).
Анализ загруженности оборудования
Если производительность системы признана удовлетворительной, то этот шаг можно пропустить. Переходите к следующему шагу: мониторингу производительности системы.
Если производительность системы признается неудовлетворительной или недостаточной, то необходимо провести анализ загруженности оборудования в соответствии с данными рекомендациями базы знаний.
Если в результате анализа будет выявлена чрезмерная загруженность оборудование, то производительность системы может быть повышена путем аппаратного апгрейда (увеличения производительности аппаратного компонента, который является узким местом).
Если этот путь является нецелесообразным или несвоевременным (например, ввиду высокой стоимости апгрейда), то следует переходить к оптимизации системы. Если аппаратный апгрейд был проведен и не принес достаточного прироста производительности, следует также переходить к оптимизации системы.
Мониторинг производительности системы
Если производительность системы признана неудовлетворительной или недостаточной, то этот шаг можно пропустить. Переходите непосредственно к оптимизации системы.
Мониторинг производительности системы рекомендуется использовать в том случае, если текущая производительность признается удовлетворительной.
Мониторинг позволит решить следующие задачи:
• Собирать и накапливать объективную информацию о производительности системы.
• Оперативно диагностировать проблемы производительности.
• Выявлять скрытые проблемы производительности. При определенных условиях (например, в начале работы системы, когда информационная база содержит незначительное количество данных) система может работать неоптимально, но пользователи системы не будут этого замечать. Впоследствии эти скрытые проблемы могут проявиться.
Для решения этой задачи рекомендуется использовать Центр управления производительностью, входящий в состав 1С:Корпоративного инструментального пакета.
Рекомендуемая последовательность действий
1. Подключитесь к исследуемой информационной базе при помощи ЦУП в режиме «Мониторинг».
Подробные инструкции по подключению см. в книге «1С:Корпоративный инструментальный пакет 8. Редакция 1.1. Руководство по использованию», стр. 37.
2. Включите сбор следующих показателей производительности:
• Запросы \ Максимальное время выполнения запроса;
• Запросы \ Среднее время выполнения запроса;
• Ожидания на блокировках \ Только блокировки СУБД \ Среднее время ожидания на блокировке СУБД;
• Ожидания на блокировках \ Только блокировки СУБД \ Количество таймаутов;
• Ожидания на блокировках \ Только блокировки 1С \ Среднее время ожидания на блокировке 1С;
• Взаимоблокировки \ Количество взаимоблокировок.


Подробные инструкции см. там же, на стр. 41.
3. Включите запись всех показателей производительности (см. там же, на стр. 45).

4. Рекомендуется осуществлять постоянный мониторинг и вести запись показателей в течение всего «срока жизни» системы.
Оценка значений показателей, поиск симптомов проблем
Для того чтобы понять, имеются ли в системе проблемы производительности, необходимо иметь критерии оценки полученных значений показателей. В настоящей главе перечислены основные симптомы проблем производительности в работающих многопользовательских системах. В том случае, если в системе наблюдаются симптомы проблем производительности, следует переходить к анализу проблем и оптимизации системы.
Симптом 1
Значения показателя «Среднее время ожидания на блокировке СУБД» близки к значениям показателя «Среднее время выполнения запроса». Это означает, что большую часть времени система простаивает в ожиданиях на блокировках СУБД. Если время ожиданий составляет 50 % от времени выполнения запросов, то проблему необходимо расследовать. Если это соотношение еще больше, то проблема является серьезной.

Симптом 2
Не равны нулю значения следующих показателей:
• «Количество взаимоблокировок»;
• «Количество таймаутов».
Это означает, что в системе наблюдаются взаимоблокировки и/или таймауты, то есть пользователи получают соответствующие сообщения об ошибках.

Симптом 3
В течение длительного времени наблюдается практически линейный рост показателя «Максимальное время выполнения запроса», после чего следует его падение до обычных значений. Это означает, что в системе выполнялся один или несколько длительных запросов, которые, вероятно, могут быть оптимизированы.

Симптом 4
Наблюдается постепенный значительный рост или внезапный «всплеск» значений следующих показателей:
• «Среднее время выполнения запроса»;
• «Среднее время ожидания на блокировке СУБД»;
• «Среднее время ожидания на блокировке 1С».
Это означает, что производительность системы со временем ухудшается, что может свидетельствовать о наличии в системе неоптимальных запросов.

Анализ проблем производительности и оптимизация системы
Анализ проблем производительности и оптимизация системы состоят из следующих основных этапов:
• Сбор аналитической информации о проблемах производительности;
• Цикл по основным проблемам производительности в порядке убывания их важности (степени влияния на общую производительность системы);
• Анализ проблем, обнаруженных в данной строке кода.
Сбор аналитической информации о проблемах производительности
Если производительность системы признана неудовлетворительной (или недостаточной) или в результате мониторинга производительности обнаружены симптомы проблем производительности, необходимо собрать аналитическую информацию о проблемах.
Для этого следует выполнить следующую последовательность действий:
1. Добавить к списку показателей все показатели производительности, входящие в группу «Анализ».

Вы можете не добавлять в список показатель «Анализ взаимоблокировок» в том случае, если уверены, что взаимоблокировок в системе нет. Например, система работала в однопользовательском режиме или в многопользовательском режиме не наблюдалось отличное от нуля значения показателя «Количество взаимоблокировок».

Вы можете не добавлять в список показатель «Анализ ожиданий на блокировках» в том случае, если вы уверены, что в системе нет ожиданий на блокировках. Например, система работала в однопользовательском режиме или в многопользовательском режиме значения показателей «Суммарное время ожидания на блокировках СУБД» и «Суммарное время ожидания на блокировках 1С» было близко к нулю.
Это позволит несколько уменьшить количество информации, собираемой ЦУП, и сократит время ее обработки.
2. Включить запись всех трех показателей
Запись показателей необходимо включать в то время, когда в системе наблюдаются проблемы производительности. Если проблемы наблюдаются не всегда, а только эпизодически (в определенных режимах работы, в период предельной загрузки системы и т. д.), то следует включать сбор аналитической информации именно в это время.
ВНИМАНИЕ!
Включение записи аналитических показателей может привести к замедлению работы системы.
3. Собирать аналитическую информацию в течение необходимого и достаточного периода времени
Период сбора аналитической информации необходимо выбирать исходя из следующих факторов:
• Время сбора аналитической информации не может быть менее 1 минуты. Рекомендуемое минимальное время – 2 минуты.
• За время сбора информации должна успеть проявиться значительная часть наблюдающихся в системе проблем. То есть период сбора информации должен быть достаточно большим.
• Чем дольше собирается аналитическая информация, тем дольше она будет анализироваться. То есть период сбора информации не должен быть слишком большим.
Как правило, для сбора исчерпывающей информации по основным проблемам, имеющимся в системе, достаточно включить запись аналитических показателей на 10–15 минут.
4. Отключить запись аналитических показателей
После отключения записи аналитических показателей ЦУП произведет анализ собранных данных и поместит результаты анализа в свою информационную базу. Время анализа данных пропорционально периоду сбора аналитической информации и может быть значительным.
Цикл по основным проблемам производительности
Для анализа проблем производительности и оптимизации системы необходимо выполнить следующую последовательность действий.
1. Перейти в режим анализа собранной информации
Для этого необходимо подключиться к исследуемой базе в режиме «Просмотр». Если отключение мониторинга нежелательно (необходимо обеспечить постоянный мониторинг производительности в исследуемой базе), то следует открыть новое соединение с информационной базой ЦУП и подключиться к исследуемой базе в режиме «Просмотр».
2. Выбрать период времени, на котором собиралась аналитическая информация
Для упрощения работы с различными периодами времени рекомендуется использовать закладки. См. «Руководство по использованию», стр. 60.
3. Открыть форму анализа проблем производительности

Оптимизация и скорость выполнения программного кода имеет немаловажное значение при разработке программных продуктов на базе 1С . Технологические платформы 8 имеют встроенный механизм замера производительности в режиме отладки для определения времени выполнения той или иной команды .

Для активации данного инструмента необходимо перейти в режим конфигуратора, открыть необходимый модуль и установить точку останова в интересующим нас месте. после переходим Отладка-Замер производительности и запускаем 1С Предприятие из под конфигуратора.

В открывшемся окне мы видим напротив каждой строки сколько раз она была выполнена, сколько времени в процентах заняло ее выполнение от общего времени, а в управляемом режиме еще и указывает где выполняется — на клиенте или на сервере.

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