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

Медленная работа 1С почти всегда имеет конкретную причину: тяжёлый запрос к базе данных, избыточные серверные вызовы, нехватка ресурсов сервера или неоптимальный код конфигурации. Чтобы найти эту причину, недостаточно «на глаз» оценить скорость — нужен замер: фиксация времени выполнения конкретной операции и разбор того, на что ушло это время.

Платформа 1С:Предприятие предоставляет для этого встроенные средства: функцию ТекущаяУниверсальнаяДатаВМиллисекундах() для точечных замеров кода, технологический журнал для анализа обращений к СУБД и центр управления производительностью (ЦУП) для комплексного мониторинга. Дополнительно используются инструменты самой СУБД — планы запросов в MS SQL Server или PostgreSQL.

Правильный подход — измерять не систему «вообще», а конкретный сценарий: проведение документа, формирование отчёта, открытие формы списка. Только воспроизводимый замер позволяет сравнить состояние «до» и «после» оптимизации и доказать, что проблема действительно устранена.

Что именно нужно измерять

Прежде чем запускать инструменты, определите объект замера. Производительность 1С складывается из нескольких независимых показателей, и смешивать их нельзя: «тормозит отчёт» и «тормозит запись документа» — это разные проблемы с разными причинами.

Основные объекты замера: время выполнения прикладной операции (проведение документа, расчёт, формирование отчёта), время выполнения отдельных запросов к СУБД, длительность серверных вызовов при работе формы, нагрузка на сервер (CPU, память, дисковая подсистема) и время отклика у пользователя. Для каждого объекта существует свой инструмент и своя методика.

Важно зафиксировать эталон: замерьте проблемную операцию несколько раз в типичных условиях и запишите результаты. Без эталона невозможно понять, дала ли оптимизация эффект, или время просто «плавало» от запуска к запуску.

Точечный замер времени выполнения кода

Самый простой способ понять, сколько выполняется конкретный участок кода, — обернуть его замером. Встроенная функция ТекущаяУниверсальнаяДатаВМиллисекундах() возвращает время с точностью до миллисекунд, чего достаточно для большинства прикладных задач.

НачалоЗамера = ТекущаяУниверсальнаяДатаВМиллисекундах();
// ... измеряемый код ...
Длительность = ТекущаяУниверсальнаяДатаВМиллисекундах() - НачалоЗамера;
Сообщить("Время выполнения: " + Длительность + " мс");

Замер выполняйте минимум 3–5 раз и берите среднее или медианное значение: первый запуск часто медленнее из-за прогрева кэша СУБД и компиляции кода. Если результаты сильно различаются между запусками, это само по себе диагностический признак — возможно, влияют блокировки других пользователей или фоновые задания.

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

1. 1
   Выделите воспроизводимую операцию и эталонные данные для неё
2. 2
   Вставьте замер до и после измеряемого участка кода
3. 3
   Выполните операцию 3–5 раз, зафиксируйте все результаты
4. 4
   Разбейте долгие участки на этапы и замерьте каждый
5. 5
   Сравните результаты после любых изменений с эталоном

Анализ запросов через технологический журнал

Большинство проблем производительности в клиент-серверной 1С связано с запросами к СУБД. Технологический журнал позволяет увидеть, какие запросы реально выполняются, сколько времени каждый занимает и сколько строк возвращает.

Чтобы включить сбор событий, создайте файл logcfg.xml в каталоге conf сервера 1С (или в каталоге, заданном параметром) с нужными фильтрами. Для анализа производительности обычно включают события DBMSSQL или DBPOSTGRS с указанием порога длительности, а также события EXCP для ошибок и TLOCK/TDEADLOCK для блокировок.

После воспроизведения проблемной операции журнал анализируют: ищут самые долгие запросы, запросы, выполняющиеся многократно в цикле (характерный признак — сотни одинаковых запросов с разными параметрами), и обращения, возвращающие избыточный объём данных. Найденный запрос затем разбирают на уровне СУБД через план выполнения.

Комплексный мониторинг через ЦУП

Центр управления производительностью (ЦУП) — отдельная конфигурация от фирмы «1С», предназначенная для постоянного контроля производительности крупных внедрений. Она собирает показатели с кластера серверов, строит графики APDEX, фиксирует самые медленные операции и позволяет расследовать инциденты задним числом.

ЦУП оправдан, когда системой пользуются десятки и сотни сотрудников и нужно отвечать на вопрос «что тормозило вчера в 11 утра». Для небольшой базы развёртывание ЦУП избыточно — достаточно точечных замеров и технологического журнала.

Ключевая метрика ЦУП — индекс APDEX, показывающий долю операций, уложившихся в целевое время. Для каждой типовой операции задаётся целевое время (например, проведение документа — до 2 секунд), после чего система автоматически выявляет операции-нарушители и накапливает по ним статистику.

Типичные узкие места и как их обнаружить

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

Вторая частая причина — неоптимальные запросы: соединения с виртуальными таблицами без отбора, условия по неиндексированным полям, выборка всех полей вместо нужных. Такие запросы выявляются по большой длительности в ТЖ и разбираются через план запроса в СУБД.

Третья группа — избыточные серверные вызовы в управляемых формах: обращение к серверу при каждом изменении поля, пересчёт данных на сервере там, где можно работать на клиенте. Замеряется через счётчики вызовов в ТЖ (события CALL) и анализ кода формы. Отдельно стоит проверять избыточные блокировки: долгие транзакции, управляемые блокировки по широким диапазонам данных.

Проверка результата оптимизации

Любое изменение — переписанный запрос, добавленный индекс, перенос кода на клиента — должно подтверждаться повторным замером в тех же условиях, что и исходный. Те же данные, та же операция, то же число запусков.

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

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