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

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

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

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

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

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

Дополнительно используются средства самой СУБД: план запроса в MS SQL Server или PostgreSQL, динамические представления, профилировщик. Часто замер в 1С показывает, что время уходит в запрос, а причину — отсутствующий индекс или неоптимальный план — видно только на стороне СУБД.

Как сделать замер в конфигураторе

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

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

1. 1
   Запустите отладку и дойдите до точки перед проблемной операцией
2. 2
   Включите замер: Отладка — Замер производительности — Начать замер
3. 3
   Выполните операцию в клиентском приложении один раз
4. 4
   Остановите замер и отсортируйте результат по чистому времени
5. 5
   Повторите замер 2–3 раза и сравните, чтобы исключить случайные всплески

Важно учитывать, что замер в конфигураторе сам по себе замедляет выполнение — отладка добавляет накладные расходы. Поэтому абсолютные цифры в этом режиме ориентировочные, а вот относительная картина (какая строка съедает большую часть времени) достоверна.

Технологический журнал: что и как фиксировать

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

Чтобы не собирать гигабайты мусора, в logcfg.xml настраивают фильтры: например, фиксировать только запросы длительнее определённого порога через свойство duration. Типовой подход — задать порог 1–3 секунды для интерактивных операций и анализировать всё, что его превышает.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs" history="24">
    <event><eq property="name" value="DBMSSQL"/></event>
    <event><eq property="name" value="TLOCK"/></event>
    <property name="all"/>
  </log>
</config>

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

ЦУП и постоянный мониторинг

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

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

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

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

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

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

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

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

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

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

Частые вопросы