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

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

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

Материал рассчитан на разработчиков и администраторов, которые работают в конфигураторе 1С 8.3. Рассмотрим включение замера, чтение таблицы результатов, анализ запросов и ограничения инструмента, а также типичные ошибки, которые искажают результаты измерений.

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

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

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

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

1. 1
   Откройте конфигуратор и запустите отладку (F5)
2. 2
   Включите замер: Отладка → Замер производительности
3. 3
   В клиентском приложении выполните измеряемую операцию один раз
4. 4
   Вернитесь в конфигуратор и выключите замер той же командой
5. 5
   Изучите таблицу результатов, отсортировав по колонке времени
6. 6
   Сохраните замер в файл при необходимости сравнения «до/после»

Как читать таблицу результатов

Окно результатов содержит дерево вызовов и таблицу строк кода. Основные колонки: «Модуль», «Номер строки», «Количество вызовов», «Время (чистое)», «Время (с вызовами)», «Доля времени». Чистое время — сколько выполнялась сама строка; время с вызовами включает всё, что строка вызвала (процедуры, функции, запросы).

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

Колонка «Количество вызовов» помогает отличить две разные проблемы. Строка выполнилась 1 раз за 30 секунд — медленная сама по себе (тяжёлый запрос). Строка выполнилась 50 000 раз по 0,001 секунды — быстрая, но вызывается слишком часто; оптимизировать нужно алгоритм, а не саму строку.

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

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

Для анализа запроса, найденного замером, скопируйте его текст в консоль запросов и посмотрите план выполнения на уровне СУБД (для MS SQL — через SQL Server Management Studio, для PostgreSQL — через EXPLAIN). Замер показывает факт медленности, но не причину на уровне СУБД: нехватку индекса, сканирование таблицы, блокировки.

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

Замер в файловом и клиент-серверном режимах

В файловом режиме замер работает без дополнительной настройки — весь код выполняется в одном процессе, и отладчик видит его целиком. В клиент-серверном варианте ситуация сложнее: серверный код выполняется в процессе рабочего сервера (rphost), и для его замера сервер должен быть запущен с включённой отладкой.

Чтобы включить отладку на сервере 1С, службу агента сервера перезапускают с ключом отладки (параметр -debug в строке запуска службы). После этого в конфигураторе через «Отладка → Подключение» можно подключить нужный серверный сеанс. Без этого шага замер покажет только клиентскую часть кода, а серверные вызовы отобразятся как единые строки без детализации.

Альтернативные и дополняющие инструменты

Замер производительности — не единственный способ диагностики. Технологический журнал (ТЖ) фиксирует события на уровне платформы и СУБД: длительные запросы (события DBMSSQL, DBPOSTGRS), блокировки (TLOCK, TDEADLOCK), длительные вызовы. ТЖ незаменим, когда проблема проявляется вне отладочного сеанса — например, в регламентных заданиях или под нагрузкой реальных пользователей.

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

Чем измерять производительность

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

Точечный анализ кода до строки; требует сеанса отладки; не видит план запроса на уровне СУБД

Технологический журнал

Фиксирует длительные запросы и блокировки в реальной работе без отладки; требует настройки logcfg.xml и навыка разбора логов

Центр управления производительностью

Постоянный мониторинг метрик серверов и СУБД; избыточен для разовой оптимизации одного отчёта

Средства СУБД (план запроса, профилировщик)

Показывают причину медленного запроса на уровне базы; не привязаны к коду конфигурации

Как подтвердить эффект оптимизации

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

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

Контрольные точки

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

Общее время операции

Норма

Время сократилось при повторных прогонах на тех же данных

Тревожный признак

Время колеблется случайно или сократилось только при первом прогоне

Строка-лидер прежнего замера

Норма

Её доля во времени заметно снизилась или она исчезла из верхних позиций

Тревожный признак

Строка осталась на прежнем месте с тем же временем

Количество вызовов

Норма

Число вызовов тяжёлой функции сократилось на порядки (например, запрос вынесен из цикла)

Тревожный признак

Количество вызовов не изменилось — оптимизирована не та часть кода

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

Почему кнопка замера производительности неактивна?

Замер доступен только при запущенном сеансе отладки. Начните отладку (F5), дождитесь запуска клиентского приложения — кнопка станет активной. Если операция выполняется в фоновом задании, дополнительно подключите его сеанс через «Отладка → Подключение».

Можно ли сделать замер без конфигуратора?

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

Почему результаты замера каждый раз разные?

На время влияют кеш СУБД, фоновые процессы, загрузка сервера и сети. Первый прогон обычно медленнее последующих. Для надёжных выводов выполняйте операцию 3–5 раз и ориентируйтесь на устоявшиеся значения, а не на единичный замер.

Замер показывает, что время уходит на выполнение запроса. Что делать дальше?

Скопируйте текст запроса в консоль запросов, проверьте отборы по виртуальным таблицам и соединения. Затем посмотрите план выполнения средствами СУБД: сканирование таблицы вместо поиска по индексу указывает на отсутствие подходящего индекса по полям отбора или соединения.

Мешает ли включённый замер точности измерений?

Сам замер добавляет небольшие накладные расходы, но они распределяются равномерно и не искажают картину относительных долей: строка-лидер останется лидером. Для сравнения «до/после» это некритично, если оба замера сделаны в одинаковых условиях.

Как измерить производительность регламентного задания?

На сервере с включённой отладкой найдите сеанс фонового задания в окне «Отладка → Подключение», подключитесь к нему и включите замер до старта задания. Альтернатива — технологический журнал с фильтром по длительности событий, который не требует ручного подключения.