При разработке и оптимизации отчетов в 1С, особенно основанных на Системе Компоновки Данных (СКД), часто возникает вопрос: как определить, сколько времени занимает именно формирование отчета из уже полученных данных, после того как запрос к базе данных выполнен? Время выполнения самого запроса обычно легко измерить, например, в консоли запросов или программно. Однако зачастую именно этап компоновки и вывода данных может оказаться "узким местом". Давайте подробно разберем, как мы можем измерить «чистое» время выполнения отчета после запроса, используя различные инструменты платформы 1С.
В платформе 1С существуют мощные механизмы, которые позволяют нам не только измерить общее время выполнения отчета, но и детализировать его по различным этапам, включая постобработку данных и вывод результата. Мы рассмотрим несколько ключевых подходов, которые помогут нам ответить на этот вопрос.
Это один из самых детализированных и мощных инструментов для анализа производительности кода в 1С. Он позволяет нам увидеть, сколько времени выполняется каждый фрагмент кода, включая те, что отвечают за обработку данных СКД после выполнения запроса.
Для начала работы с этим инструментом нам необходимо открыть Конфигуратор 1С. Переходим в меню Отладка и выбираем пункт Замер производительности. В открывшемся окне нажимаем кнопку Начать.
Важно: для получения полной картины, включающей время выполнения серверного кода, убедитесь, что отладка на сервере 1С:Предприятия активирована. Это позволит нам проанализировать весь цикл выполнения отчета.
После активации замера производительности, нам нужно перейти в режим 1С:Предприятие и выполнить тот отчет, который мы хотим проанализировать. Выполняем отчет с различными настройками компоновки, чтобы оценить влияние этих настроек на производительность.
После завершения выполнения отчета возвращаемся в Конфигуратор и нажимаем кнопку Завершить в окне «Замер производительности». Перед нами откроется таблица с результатами замера. В этой таблице мы увидим детальную информацию о каждом вызове функций и процедур, а также времени их выполнения.
Обратите особое внимание на следующие колонки:
Мы будем искать фрагменты кода, которые относятся к процессу компоновки и вывода отчета. Обычно это методы, связанные с объектами КомпоновщикМакетаСКД, МакетКомпоновкиДанных, ПроцессорКомпоновкиДанных, ПроцессорВыводаРезультатаКомпоновкиДанных, а также процедуры, отвечающие за обработку данных в модулях менеджеров или модулях объектов отчетов после получения результата запроса (например, различные циклы по выборкам, заполнение дополнительных полей, условное оформление и т.д.).
Если в нашем отчете используются программные обработки результата запроса, например, доп. поля, вычисляемые в циклах, или сложная логика условного оформления, то именно эти участки кода будут отображены в замере производительности с указанием их «чистого» времени выполнения.
Мы рекомендуем выполнить несколько замеров (минимум 5-6 раз) для одного и того же сценария. Это связано с тем, что первое выполнение операции часто может занимать больше времени из-за кэширования данных и компиляции кода. Усредненные результаты дадут нам более точную картину.
Для комплексного и системного мониторинга производительности, особенно в типовых конфигурациях 1С, мы можем использовать подсистему «Оценка производительности» из БСП. Этот инструмент ориентирован на измерение производительности «ключевых операций», к которым относятся и формирование отчетов.
Подсистема использует международный стандарт APDEX (Application Performance Index), который измеряет уровень удовлетворенности пользователей временем отклика системы. Она автоматически собирает статистику по заранее определенным ключевым операциям (таким как проведение документов, формирование отчетов и т.д.) в фоновом режиме.
Для включения замера производительности через БСП нам нужно перейти в раздел Администрирование – Обслуживание и установить флажок Оценка производительности. Здесь же мы можем настроить профили ключевых операций, задать целевое время выполнения и приоритет для каждой операции.
Нас интересует ключевая операция, связанная с формированием нашего отчета. Если отчет типовой, она, скорее всего, уже настроена. Если это наш собственный отчет, нам может потребоваться добавить его в список ключевых операций, если мы хотим использовать APDEX. Для автоматизации этого процесса подойдёт обработка для добавления ключевых операций в профиль производительности.
После сбора данных мы можем открыть отчет Оценка производительности (обычно находится в том же разделе Администрирование – Обслуживание). Этот отчет предоставляет нам агрегированную информацию о времени выполнения ключевых операций в разрезе пользователей, периодов и различных параметров.
Хотя БСП не предоставляет детализацию до уровня строк кода, как «Замер производительности», она дает нам общее «чистое» время выполнения всей операции по формированию отчета. Сравнивая это время с временем выполнения запроса (измеренного отдельно), мы можем косвенно оценить время, затрачиваемое на постобработку и вывод.
Преимущества БСП: Подсистема оценки производительности БСП позволяет нам выявлять общие «узкие места» и приоритезировать их оптимизацию на системном уровне. Она предоставляет «чистое» время работы, которое означает активные действия системы без учета ожиданий или простоев, что важно для анализа.
Для точечного замера времени выполнения определенных участков кода, особенно в модулях объектов отчетов или в обработчиках событий СКД, мы можем использовать программный замер времени.
Этот метод полезен, когда мы хотим точно измерить, сколько времени занимает конкретный блок кода, например, цикл по выборке или сложный алгоритм заполнения дополнительных полей после получения данных из запроса.
Пример такого замера:
НачалоЗамера = ТекущаяДата();
// Здесь располагается наш код, который мы хотим измерить,
// например, обработка результата запроса,
// создание табличных документов, заполнение областей и т.д.
КонецЗамера = ТекущаяДата();
РазницаВСекундах = (КонецЗамера - НачалоЗамера);
Сообщить("Время выполнения блока кода: " + РазницаВСекундах + " сек.");
Мы можем размещать такие блоки замера в различных точках жизненного цикла формирования отчета: после выполнения запроса, перед началом вывода на форму, перед печатью и так далее. Это позволит нам разделить общий процесс на более мелкие этапы и точно определить, какой из них занимает наибольшее время после работы с СУБД.
Например, в обработчике события ПриКомпоновкеРезультата или в функции СформироватьОтчет мы можем окружить программными замерами участки кода, которые работают с объектами ПроцессорКомпоновкиДанных и ПроцессорВыводаРезультатаКомпоновкиДанных, а также любые циклы обработки данных.
Технологический журнал 1С предоставляет еще более низкоуровневую информацию о работе платформы. Он может быть полезен, когда нам нужно понять, сколько суммарного времени выполняются все запросы от одной операции, и сравнить это с общим временем выполнения отчета, измеренным по секундомеру или другими способами.
Настраивая события DBMSSQL, DBPOSTGRS, DBORACLE или DB2 (в зависимости от нашей СУБД) с уровнем детализации 5, мы можем получить подробные логи всех запросов к базе данных, их длительность и параметры. Анализируя эти данные совместно с событиями CALL (вызовы серверных процедур) и SCOM (работа СКД), мы можем попытаться выделить время, которое не было потрачено на запросы, но было потрачено платформой на другие операции, включая постобработку и формирование.
Хотя анализ Технологического журнала требует более глубоких знаний и инструментов для парсинга логов, он может предоставить самую полную картину, включая время, затраченное на внутренние платформенные вызовы, которые мы не видим в коде. Для удобного сбора и хранения таких данных можно использовать утилиту для переноса логов технологического журнала в ClickHouse.
Для наиболее эффективного замера времени, которое уходит непосредственно на построение отчета из результата запроса, мы рекомендуем сочетать несколько методов:
ПроцессорКомпоновкиДанных, ПроцессорВыводаРезультатаКомпоновкиДанных) и наши собственные программные алгоритмы.Комбинируя эти подходы, мы сможем не только точно измерить время, затрачиваемое на каждый этап формирования отчета, но и эффективно выявить и устранить «узкие места», значительно улучшив производительность наших отчетов в 1С.