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

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

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

Типичный сценарий применения — диагностика медленного проведения документов, долгого формирования отчётов, зависания обменов данными. Замер одинаково полезен разработчику, который оптимизирует свой код, и администратору, который ищет источник нагрузки на сервер.

Что именно измеряет механизм и какие ограничения есть

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

Чистое время — ключевая колонка. Если процедура «ПровестиДокумент» заняла 10 секунд, но 9,5 из них ушло на вложенный запрос, именно запрос — точка оптимизации, а не сама процедура. Сортировка по чистому времени сразу показывает такие строки.

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

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

Замер запускается из конфигуратора в режиме отладки. Порядок действий одинаков для тонкого и толстого клиента, для файловых и клиент-серверных баз.

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

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

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

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

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

Первый приём — отсортировать по чистому времени и посмотреть верхние 5–10 строк. В большинстве реальных случаев 80% времени занимают единицы строк: тяжёлый запрос, обращение к СУБД в цикле, длительная обработка большой таблицы значений.

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

Типичные узкие места, которые выявляет замер

Самая частая находка — запрос в цикле. Код перебирает строки табличной части и для каждой выполняет запрос к остаткам или ценам. Замер показывает тысячи вызовов одной строки. Решение — один запрос по всей таблице с соединением или временной таблицей, а результаты обходятся в памяти.

Вторая классика — обращение к реквизитам объекта через точку в цикле: Строка.Номенклатура.Артикул внутри перебора вызывает отдельное чтение из базы на каждой итерации. Выгрузка нужных полей одним запросом убирает проблему полностью.

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

Запросы и временные таблицы

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

// Плохо: запрос в цикле
Для Каждого Строка Из Товары Цикл
    Запрос.УстановитьПараметр("Номенклатура", Строка.Номенклатура);
    Выборка = Запрос.Выполнить().Выбрать();
КонецЦикла;

// Хорошо: один запрос по всей таблице
Запрос.УстановитьПараметр("Товары", Товары.Выгрузить());
Выборка = Запрос.Выполнить().Выбрать();

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

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

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

Когда замера недостаточно: технологический журнал и средства СУБД

Замер показывает код встроенного языка, но не видит, что происходит внутри СУБД: блокировки, ожидания, неоптимальные планы запросов. Если замер указывает на запрос, а сам запрос выглядит нормально, следующий шаг — технологический журнал с событиями DBMSSQL/DBPOSTGRS и TLOCK.

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

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

FAQ