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

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

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

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

Подготовка: на каких данных и в каком режиме замерять

Результат замера сильно зависит от условий. Один и тот же отчет на пустой демо-базе сформируется за секунду, а на рабочей базе с миллионами записей — за десятки минут. Поэтому первое правило: замерять нужно на копии рабочей базы с реальным объемом данных или на самой рабочей базе в непиковое время.

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

Третий фактор — кэш и «прогрев». Первое формирование отчета после перезапуска сервера почти всегда медленнее: СУБД читает данные с диска, а не из памяти. Чтобы сравнение было честным, выполните отчет два-три раза и берите среднее или медианное значение, отбрасывая первый прогон.

Быстрый замер времени формирования отчета

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

Пример фрагмента кода для модуля отчета:

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

// ... код формирования отчета: заполнение параметров,
// компоновка настроек, вывод в табличный документ ...

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

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

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

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

Детальный анализ через «Замер производительности» в конфигураторе

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

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

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

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

Особенности замера в клиент-серверном режиме

В клиент-серверном варианте отчет обычно формируется на сервере. Чтобы увидеть серверный код в замере, в свойствах базы в конфигураторе включите отладку серверных вызовов (протокол отладки по TCP/IP и разрешение отладки в свойствах информационной базы). Без этого в замере будут видны только клиентские строки, а реальная картина останется скрытой.

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

Если основное время уходит на выполнение запроса, замер кода уже мало что даст — нужно смотреть, что происходит на стороне СУБД. Для этого настраивается технологический журнал (файл logcfg.xml) с событиями DBMSSQL или DBPOSTGRS и длительностью выполнения. В логе виден текст запроса в терминах СУБД и время его выполнения.

Полученный запрос можно выполнить напрямую в средствах СУБД (SQL Server Management Studio, pgAdmin) с включенным показом плана запроса. План покажет, используются ли индексы, есть ли полные сканирования таблиц (table scan, seq scan) — типичная причина медленных отчетов на больших объемах.

Типичные запросные причины медленного отчета: соединение с виртуальными таблицами без отборов, условия по неиндексированным полям, использование функций над полями в условиях (например, сравнение с НАЧАЛОПЕРИОДА в соединении), обращение к полям через точку от ссылочных полей («разыменование»), которое порождает множество скрытых соединений.

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

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

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

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

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

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

Вторая ошибка — сравнение «холодного» и «теплого» прогона. Если до оптимизации вы мерили первый запуск, а после — третий, разница объясняется кэшем СУБД, а не вашими изменениями. Всегда приводите прогоны к одинаковым условиям.

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

Инструменты для регулярного контроля производительности

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

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

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

Для разовых глубоких расследований полезны консоль кода и консоль запросов с возможностью замера, а также штатный просмотр технологического журнала. Выбор инструмента зависит от масштаба задачи и бюджета.

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