Разработка и Конфигурация · 11 мин
Как пользоваться замером производительности (профилировщиком) в 1С
Как включить и использовать замер производительности в конфигураторе 1С: настройка, чтение результатов, поиск узких мест в коде и типичные ошибки при профилировании.
Замер производительности — встроенный профилировщик конфигуратора 1С, который показывает, сколько времени занимает выполнение каждой строки кода и каждого вызова процедуры. С его помощью разработчик находит медленные запросы, лишние обращения к базе данных и фрагменты кода, которые тормозят проведение документов, формирование отчётов или обмены данными.
Инструмент работает в режиме отладки и не требует установки сторонних программ. Результат замера представляется в виде таблицы с колонками времени выполнения, количества вызовов и доли каждой строки в общем времени. Этого достаточно, чтобы за несколько минут понять, где «утекает» производительность, вместо того чтобы гадать и переписывать код вслепую.
Профилировщик применим как в файловых, так и в клиент-серверных базах. В клиент-серверном варианте он показывает в том числе время, затраченное на сервере, что критично при анализе запросов к СУБД. Ниже разобраны включение замера, чтение результатов, практические сценарии оптимизации и ограничения инструмента.
Что такое замер производительности и когда он нужен
Замер производительности — это профилировщик, который во время отладки фиксирует, сколько раз выполнилась каждая строка модуля и сколько времени на неё ушло. В отличие от субъективного ощущения «тормозит», он даёт точные цифры: конкретная строка, конкретный запрос, конкретное время в секундах и процентах от общей длительности.
Инструмент нужен в ситуациях, когда операция выполняется недопустимо долго: документ проводится минутами, отчёт строится полчаса, обмен выгружает данные всю ночь. Также замер полезен при приёмке доработок — можно сравнить время выполнения до и после изменений и объективно подтвердить эффект оптимизации.
Замер не заменяет анализ планов запросов на стороне СУБД и технологический журнал, но это самый быстрый способ локализовать проблему: сначала профилировщик показывает «горячую» строку, а уже потом имеет смысл углубляться в план конкретного запроса.
Как включить и выполнить замер
Замер выполняется только в режиме отладки. Запустите конфигуратор, подключитесь к нужной базе и запустите отладку (F5) либо подключитесь к уже работающему сеансу через меню «Отладка → Подключение». Убедитесь, что отладка разрешена: для клиент-серверной базы на сервере 1С должен быть включён режим отладки (параметр -debug), иначе подключиться не получится.
Порядок действий стандартный: сначала включаете замер, затем воспроизводите медленную операцию в клиентском приложении, затем выключаете замер и анализируете результат. Важно воспроизводить именно ту операцию и с теми данными, на которых наблюдается проблема, — на тестовом документе с тремя строками запрос может вести себя иначе, чем на реальном с тремя тысячами.
- 1Откройте конфигуратор и запустите отладку (F5) или подключитесь к сеансу через «Отладка → Подключение».
- 2Включите замер: меню «Отладка → Замер производительности» — пункт станет отмечен флажком.
- 3В клиентском приложении выполните медленную операцию один раз от начала до конца, без лишних действий.
- 4Вернитесь в конфигуратор и снимите флажок «Замер производительности» — откроется окно с результатами.
- 5Сохраните результат замера в файл, если планируете сравнение «до/после» или передачу коллегам.
Как читать результаты замера
Результат представлен таблицей по строкам модулей. Ключевые колонки: «Количество вызовов» — сколько раз выполнялась строка; «Время» — суммарное время с учётом вложенных вызовов; «Время (чистое)» — время самой строки; «% времени» — доля строки в общем времени замера. Есть также колонки с временем вызова сервера и СУБД, которые помогают отделить проблемы кода от проблем запросов.
Основной приём — сортировка по чистому времени по убыванию. Строки наверху списка и есть точки оптимизации. Если наверху строка с запросом (Запрос.Выполнить() или Выбрать()) — проблема в запросе или в отсутствии индексов. Если наверху строка внутри цикла с обращением к реквизиту через точку — вероятен «запрос в цикле», классическая причина медленного кода.
Обращайте внимание на количество вызовов: строка, выполняющаяся 0,01 секунды, но вызываемая 50 000 раз, суммарно даёт 500 секунд. Такие случаи лечатся не ускорением строки, а уменьшением числа вызовов — выносом запроса из цикла, кэшированием, групповой обработкой.
Как проверить результат замера
Это реальная точка оптимизации — запрос или тяжёлая операция
На первом месте служебная строка ожидания — замер захватил паузы пользователя
Соответствует логике алгоритма (например, числу строк документа)
В десятки раз больше ожидаемого — вероятен запрос или обращение к БД в цикле
Большая часть времени — на стороне СУБД: оптимизируйте запрос и индексы
Время уходит на код клиента/сервера без запросов: ищите лишние циклы и обращения через точку
Практические сценарии оптимизации
Медленное проведение документа
Включите замер, проведите один проблемный документ, остановите замер. Чаще всего в результатах видны обращения к остаткам регистров в цикле по строкам табличной части. Решение — один запрос с группировкой по всем позициям документа вместо запроса на каждую строку, а также контроль того, что запрос по остаткам использует индексированные поля измерений.
Долго формируется отчёт
Замер покажет, что медленнее: сам запрос отчёта или постобработка результата в коде. Если тяжёлая строка — СхемаКомпоновкиДанных или вывод результата, смотрите настройки СКД: ресурсы, вычисляемые поля, соединения на уровне набора данных. Если тяжёлый именно запрос — переходите к анализу его плана средствами СУБД.
Медленный обмен или загрузка данных
При обменах типичная картина — тысячи вызовов поиска объекта по ссылке или реквизиту, каждый из которых идёт в базу отдельным запросом. Замер с колонкой «Количество вызовов» выявляет это мгновенно. Оптимизация обычно сводится к предварительной выборке соответствий одним пакетным запросом и поиску в памяти.
Перед замером прогрейте операцию один раз без замера: первый запуск может включать компиляцию модулей и кэширование, которые исказят картину. Замеряйте второй или третий прогон — так результаты будут ближе к реальной работе пользователей.
Ограничения и риски при профилировании
Сам включённый замер замедляет выполнение кода — накладные расходы профилировщика могут увеличить время операции в несколько раз. Абсолютные цифры времени в замере завышены, но относительные пропорции между строками обычно сохраняются, поэтому для поиска узких мест этого достаточно. Не пытайтесь по цифрам замера оценивать реальное время работы в продуктиве.
Проводить замер в работающей продуктивной базе следует осторожно: отладка и замер создают дополнительную нагрузку, а точки останова способны остановить выполнение кода для отлаживаемого сеанса. По возможности воспроизводите проблему на копии базы с актуальными данными — объёмы данных часто определяют поведение запросов.
Ещё одно ограничение: профилировщик показывает код 1С, но не раскрывает, что происходит внутри СУБД. Если замер указывает на строку выполнения запроса, дальнейший анализ — это план запроса, индексы и статистика на стороне MS SQL, PostgreSQL или Oracle.
Типичные ошибки при работе с замером
Самая частая ошибка — замер «всего подряд». Пользователь включает профилировщик, потом долго ходит по интерфейсу, и в результатах тонет полезный сигнал среди служебных вызовов. Замер должен охватывать ровно одну воспроизводимую операцию от старта до финиша.
Вторая ошибка — оптимизация по колонке «Время» вместо «Время (чистое)». Процедура верхнего уровня всегда наберёт максимум суммарного времени, потому что включает все вложенные вызовы; сортировка по ней ничего не даёт. Третья ошибка — выводы по одному замеру на нерепрезентативных данных: документ с пятью строками не покажет проблему, которая проявляется на пяти тысячах.
Чем дополнить замер производительности
Когда замер локализовал проблему в конкретном запросе, следующий шаг — анализ плана запроса. Для этого используются средства СУБД (планы выполнения в MS SQL Server Management Studio, EXPLAIN в PostgreSQL) или инструменты вроде консоли запросов с показом плана. Технологический журнал платформы помогает собрать длительные запросы и блокировки в продуктиве без отладки — события DBMSSQL, TLOCK, TDEADLOCK.
Для комплексной оценки нагрузки применяется Центр управления производительностью (ЦУП), который собирает метрики по регламентным заданиям, запросам и ожиданиям на блокировках. Замер производительности при этом остаётся инструментом первого отклика: быстро, без настройки, прямо в конфигураторе.
Инструменты анализа производительности
Быстрый поиск медленных строк кода в отладке. Не показывает план запроса и искажает абсолютное время.
Сбор длительных запросов и блокировок в продуктиве без отладки. Требует настройки logcfg.xml и разбора логов.
Глубокий анализ конкретного запроса: индексы, соединения, статистика. Требует доступа к СУБД и знания её инструментов.
Комплексный мониторинг нагрузки и ожиданий. Избыточен для разовой диагностики одной операции.
Что важно запомнить
Замер производительности включается в режиме отладки через меню «Отладка», охватывает одну целевую операцию и читается по колонке чистого времени. Большое число вызовов дешёвой строки — такой же важный сигнал, как одна дорогая строка. Для анализа самого запроса после локализации переходите к плану запроса на стороне СУБД.
Частые вопросы
Можно ли сделать замер производительности без конфигуратора?
Нет, замер доступен только в конфигураторе в режиме отладки. Для анализа в продуктиве без отладки используют технологический журнал с событием DBMSSQL или внешние инструменты мониторинга СУБД.
Почему в клиент-серверной базе не подключается отладка?
На сервере 1С:Предприятия не включён режим отладки. Сервер нужно запустить с параметром -debug (для службы агента — через реестр или параметры запуска, для rphost — через кластер). Также проверьте, что пользователь имеет право на отладку.
Чем отличается «Время» от «Время (чистое)» в результатах?
«Время» включает все вложенные вызовы из данной строки, «Время (чистое)» — только саму строку. Узкие места ищут по чистому времени, а суммарное используют, чтобы понять вклад целой ветки вызовов.
Замер показывает, что всё время уходит на строку «Запрос.Выполнить()». Что дальше?
Это значит, что проблема в самом запросе или в индексах таблиц. Скопируйте текст запроса в консоль запросов, проверьте его план средствами СУБД, убедитесь, что в условиях соединений и отборов используются индексированные поля.
Можно ли сохранить результат замера и сравнить с новым?
Да, результат замера сохраняется в файл через контекстное меню окна результатов. Сохраняйте замер «до» оптимизации и снимайте такой же «после» на тех же данных — это даёт объективное подтверждение эффекта изменений.
Почему время в замере сильно больше реального времени операции?
Профилировщик добавляет накладные расходы на фиксацию каждой строки, поэтому абсолютные значения завышены. Ориентируйтесь на относительные доли строк в процентах — они остаются показательными.