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

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

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

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

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

Замер производительности — это встроенный профилировщик платформы 1С:Предприятие. Во включённом состоянии он фиксирует каждый вызов процедуры, функции и запроса, записывая количество вызовов и суммарное время выполнения. Результат отображается в виде таблицы, привязанной к конкретным строкам модулей конфигурации.

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

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

Подготовка: права, режим работы и воспроизводимый сценарий

Для запуска замера нужны права на использование конфигуратора и режима отладки в данной информационной базе. В клиент-серверном варианте дополнительно проверьте, что на сервере 1С разрешена отладка — иначе серверный код в замер не попадёт, и картина будет неполной.

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

Идеальный вариант — развёрнуть копию базы и повторить операцию там. Это исключает влияние на пользователей и позволяет прогонять замер многократно, меняя код и сравнивая результаты до и после оптимизации.

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

Базовый сценарий одинаков для большинства версий платформы 8.3. Последовательность действий:

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

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

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

Настройка опций замера

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

• Для вызовов процедур и функций — учитывать время каждого вызова, а не только строк внутри модулей;
• Для строк модулей — построчная статистика, полезная для поиска конкретного медленного оператора;
• Для запросов — фиксация времени выполнения запросов к базе данных;
• Учитывать время на клиенте / на сервере — разделение статистики по сторонам исполнения в клиент-серверном режиме.

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

Как читать результаты замера

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

Типичные находки и их интерпретация:

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

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

Обращайте внимание на разделение клиент/сервер. Если большая часть времени уходит на клиенте при работе с формой, оптимизация запросов не поможет — смотрите в сторону объёма данных, передаваемых форме, и логики обработчиков ожидания.

Замер в клиент-серверном режиме и ЦУП

В клиент-серверной архитектуре серверный код попадает в замер только при включённой отладке на сервере. Служба агента сервера 1С должна быть запущена с параметром отладки (например, -debug в строке запуска службы). После изменения параметров службу перезапускают — это кратковременно разрывает сеансы пользователей, поэтому планируйте операцию на нерабочее время.

Для систем, где проблемы производительности возникают регулярно и под нагрузкой, разового замера недостаточно. Здесь применяют ЦУП: он по расписанию собирает замеры с рабочей базы, анализирует технологический журнал и выявляет запросы, деградирующие под реальной нагрузкой, а не в искусственном тесте.

Сравнение инструментов

Штатный замер в конфигураторе

Подходит для разовой диагностики конкретной медленной операции. Ограничение: требует ручного воспроизведения сценария и влияет на скорость выполнения.

ЦУП

Подходит для постоянного мониторинга крупных систем и поиска деградации под нагрузкой. Ограничение: требует развёртывания отдельной базы и настройки сбора данных.

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

Подходит для анализа блокировок, длительных запросов СУБД и ошибок. Ограничение: не показывает картину по строкам кода конфигурации.

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

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

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

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

Полнота замера

Норма

В таблице результатов присутствуют и клиентские, и серверные строки, суммарное время соответствует длительности операции

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

Видны только клиентские вызовы при явно серверной операции — отладка сервера не подключена

Воспроизводимость

Норма

Два-три прогона одного сценария показывают схожее распределение времени по строкам

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

Картина скачет от прогона к прогону — влияют внешние факторы, замер повторить в чистых условиях

Эффект оптимизации

Норма

После доработки доля проблемной строки или запроса заметно снизилась при том же сценарии

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

Общее время не изменилось — оптимизирован не тот участок

Часто задаваемые вопросы

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

Штатный построчный замер запускается именно из конфигуратора в режиме отладки. Без него доступны косвенные методы: технологический журнал для анализа длительных вызовов и запросов, а также программный сбор времени через встроенные средства датировки в коде. Для регулярного мониторинга без ручного запуска используется ЦУП.

Почему в замере не видно серверного кода?

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

Насколько замер замедляет работу базы?

Профилировщик добавляет накладные расходы на фиксацию каждого вызова, поэтому код во время замера выполняется медленнее обычного. Насколько именно — зависит от плотности вызовов в коде. Поэтому результаты замера сравнивают в относительных долях, а не в абсолютных секундах, и не оставляют замер включённым без необходимости.

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

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

Можно ли сохранить результаты замера для сравнения?

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

Замер на копии базы не повторяет проблему рабочей. Почему?

Производительность сильно зависит от объёма данных, состояния индексов и статистики СУБД. Если копия старая или урезанная, планы запросов будут другими. Для достоверной диагностики используйте свежую полную копию и желательно на оборудовании, сопоставимом с рабочим сервером.