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

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

Замер работает в отладочном режиме и накапливает статистику по всем строкам модулей, которые выполнялись с момента включения. Результат представляется в виде таблицы с колонками: модуль, номер строки, код, количество вызовов, чистое время, время с учётом вложенных вызовов и проценты от общего времени. Именно сопоставление «количество вызовов × время одного вызова» даёт ответ, что оптимизировать в первую очередь.

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

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

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

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

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

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

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

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

Вторая по важности колонка — «Количество вызовов». Классический признак проблемы: строка выполняется тысячи или десятки тысяч раз при операции, которая по логике должна делать один проход. Например, запрос или получение объекта из базы внутри цикла по табличной части. Даже если один вызов занимает миллисекунды, суммарно это превращается в минуты.

Обращайте внимание и на процент от общего времени. Строка, занимающая 60–80% чистого времени операции, — очевидный кандидат на оптимизацию. Десяток строк по 1–2% оптимизировать бессмысленно: эффект будет незаметен. Отсюда практическое правило — работайте сверху вниз по отсортированной таблице и останавливайтесь, когда суммарная доля разобранных строк перестаёт быть значимой.

Типичные узкие места, которые находит замер

Чаще всего замер обнажает запросы в цикле. Паттерн выглядит так: обход табличной части или выборки, и на каждой итерации — выполнение запроса, получение объекта справочника или вызов функции, которая обращается к базе. Решение почти всегда одно и то же: собрать нужные данные одним запросом до цикла (через временные таблицы, соединения или пакетный запрос) и в цикле работать только с уже выгруженной таблицей значений.

Вторая частая находка — повторные обращения к данным через точку от ссылки: конструкции вида Строка.Номенклатура.Наименование или Документ.Контрагент.ИНН внутри цикла. Каждое такое обращение может порождать отдельное обращение к базе. Замер покажет эти строки с огромным счётчиком вызовов. Лечится выборкой реквизитов запросом или использованием функции получения значений реквизитов одним пакетом.

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

Замер в клиент-серверном режиме и его ограничения

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

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

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

Как проверить эффект оптимизации

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

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

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

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

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

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

Норма

Строка ушла из верхних позиций по чистому времени

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

Строка на месте или время перешло на соседнюю строку

Количество вызовов

Норма

Число вызовов сократилось на порядки

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

Счётчик вызовов не изменился

Общее время операции

Норма

Суммарное время замера заметно снизилось

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

Время то же — эффект только косметический

Поведение на реальных данных

Норма

Пользовательская операция ускорилась на рабочих объёмах

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

Ускорение видно только на тестовой базе

Альтернативные и дополняющие инструменты

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

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

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

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

Точный анализ конкретной операции до уровня строки кода; требует отладки и воспроизведения сценария

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

Анализ запросов к СУБД, блокировок и длительных событий; сложнее настройка и большой объём логов

ЦУП

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

Оценка производительности (БСП)

Контроль времени ключевых операций в типовых конфигурациях; работает только там, где встроена подсистема

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

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

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

Почему сумма времени в таблице замера больше реального времени операции?

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

Замер показывает одну строку «Запрос.Выполнить()» на 90% времени — что делать?

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

Нужно ли оптимизировать все строки из верхней части таблицы?

Нет. Работайте по принципу убывания эффекта: сначала строки с максимальной долей чистого времени и аномальным числом вызовов. Когда оставшиеся строки дают по 1–2% времени, дальнейшая оптимизация обычно не окупается трудозатратами и риском новых ошибок.

Как замерить производительность на рабочей базе, где нельзя включать отладку?

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

Чем замер отличается от профилирования запросов?

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