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

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

Платформа 1С:Предприятие предлагает несколько способов измерения: встроенный замер производительности в конфигураторе (отладка), программный замер через объект «ОписаниеПроцедурИФункций», центр управления производительностью (ЦУП) и технологический журнал для анализа на уровне сервера. Каждый инструмент решает свою задачу — от поиска «тяжёлой» строки в модуле до диагностики блокировок СУБД.

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

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

Выбор инструмента зависит от того, что именно тормозит. Если подозрение падает на конкретный код — обработку, проведение документа, построение отчёта, — достаточно встроенного замера производительности в конфигураторе. Он работает на уровне строк встроенного языка и показывает, сколько раз вызывалась каждая строка и сколько времени она заняла.

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

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

Замер производительности через конфигуратор: пошагово

Самый доступный способ — встроенный механизм отладки. Он не требует изменения кода и работает как для файловых, так и для клиент-серверных баз, если у вас есть право на отладку и доступ к конфигуратору.

1. 1
   Откройте конфигуратор и запустите отладку: Отладка → Начать отладку (или F5). Если сеанс клиента уже запущен, подключите его через Отладка → Подключение.
2. 2
   Включите замер: Отладка → Замер производительности. Пункт должен стать отмеченным флажком.
3. 3
   Перейдите в клиентское приложение и выполните операцию, которая работает медленно: проведите документ, сформируйте отчёт, откройте форму.
4. 4
   Вернитесь в конфигуратор и снова выберите Отладка → Замер производительности — откроется окно результатов.
5. 5
   Изучите колонки: имя модуля, номер строки, количество вызовов, чистое и суммарное время, процент от общей длительности.
6. 6
   Отсортируйте по времени и найдите строки с максимальным вкладом — это и есть точки оптимизации.

В окне результатов есть важные колонки. «Количество вызовов» показывает, сколько раз выполнялась строка — большое число при малом времени одной строки часто указывает на запрос или обращение к данным внутри цикла. «Время (чистое)» — время самой строки без вложенных вызовов, «время (суммарное)» — с учётом вызванных из неё процедур. Для поиска узкого места в первую очередь смотрят именно чистое время.

Отдельный признак полезен для запросов: в замере видно, какая доля времени ушла на выполнение запроса к СУБД. Если строка «Запрос.Выполнить()» занимает основную часть времени, оптимизировать нужно запрос или индексы, а не код обхода результата.

Как читать результаты замера и находить узкие места

Типичная картина проблемного замера: одна-две строки занимают 70–90% суммарного времени, остальное распределено равномерно. Именно эти строки и стоит анализировать. Если «горячая» строка — выполнение запроса, откройте текст запроса и проверьте его план: соединения без условий по индексированным полям, выборка лишних полей, вложенные запросы вместо временных таблиц.

Если лидирует строка внутри цикла — например, обращение к реквизиту через точку от ссылки (Документ.Контрагент.ИНН), — это классический признак «запроса в цикле»: каждое обращение порождает неявное обращение к базе. Решение — получить все нужные данные одним запросом до цикла.

Обращайте внимание на количество вызовов. Строка, выполненная 50 000 раз по 0,001 секунды, суммарно «съест» 50 секунд — хотя по отдельности выглядит безобидно. В таких случаях оптимизируют алгоритм целиком: уменьшают число итераций, кэшируют результаты, выносят повторяющиеся вычисления из цикла.

Программный замер длительности фрагмента кода

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

НачалоЗамера = ТекущаяУниверсальнаяДатаВМиллисекундах();

// измеряемый фрагмент кода
ВыполнитьТяжелуюОперацию();

Длительность = ТекущаяУниверсальнаяДатаВМиллисекундах() - НачалоЗамера;
ЗаписьЖурналаРегистрации("Замер", УровеньЖурналаРегистрации.Информация,,,
    "Длительность операции, мс: " + Длительность);

В типовых конфигурациях на базе БСП есть готовые механизмы оценки производительности: подсистема «Оценка производительности» собирает замеры ключевых операций и позволяет смотреть статистику по ним. Это удобнее самописных замеров, если конфигурация типовая — механизм уже встроен и накапливает историю.

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

Технологический журнал и ЦУП для серверных проблем

Если замер в конфигураторе показывает, что время уходит на ожидание ответа СУБД, а код и запросы выглядят нормально, следующий шаг — технологический журнал. Он включается через файл logcfg.xml в каталоге конфигурации сервера (или клиента) и позволяет логировать события DBMSSQL/DBPOSTGRS (запросы к СУБД с длительностью), TLOCK и TDEADLOCK (управляемые блокировки и взаимоблокировки), CALL и EXCP (вызовы и исключения).

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

ЦУП решает задачу постоянного наблюдения: он автоматически собирает данные технологического журнала, строит показатели APDEX по ключевым операциям и показывает деградацию производительности во времени. Его имеет смысл разворачивать, когда база большая, пользователей много, а проблемы носят плавающий характер и не воспроизводятся по требованию.

Типичные ошибки при замере производительности

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

Как проверить, что оптимизация сработала

После изменения кода или запроса замер повторяют в тех же условиях: та же база, те же входные данные, тот же порядок действий. Сравнивают не только общее время операции, но и структуру замера: «горячая» строка должна исчезнуть из верхних позиций или существенно снизить долю.

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

Часто задаваемые вопросы