Администрирование · 12 мин
Замер производительности 1С: как пользоваться и что делать с результатами
Как выполнить замер производительности в 1С через конфигуратор: включение режима замера, анализ по строкам кода, ЦУП и APDEX, типичные ошибки оптимизации.
Медленное проведение документов, долгое открытие отчётов и «подвисания» интерфейса — типичные жалобы пользователей 1С. Чтобы понять, где именно теряется время, недостаточно субъективных ощущений: нужен инструментальный замер. Платформа 1С:Предприятие включает встроенный механизм замера производительности в конфигураторе, а для серверных решений существует Центр управления производительностью (ЦУП).
Замер производительности показывает, сколько времени заняла каждая строка кода и каждый запрос, сколько раз они выполнялись и какую долю общего времени составляют. Это позволяет найти «узкое место» точечно — например, запрос в цикле или обращение к СУБД без индекса — вместо того чтобы оптимизировать код наугад.
Материал ориентирован на администраторов и разработчиков 1С, которым нужно самостоятельно провести замер, прочитать его результаты и понять, что делать дальше. Рассмотрены встроенный замер конфигуратора, технологический журнал, ЦУП и типичные ошибки при интерпретации данных.
Какие инструменты замера есть в 1С и когда какой выбирать
Платформа предлагает несколько уровней диагностики, и они дополняют, а не заменяют друг друга. Встроенный замер производительности в конфигураторе показывает время выполнения по строкам встроенного языка и по запросам. Это основной инструмент разработчика при поиске медленного кода.
Технологический журнал (ТЖ) — это текстовые логи платформы, куда пишутся события: запросы к СУБД, вызовы, блокировки, ошибки. ТЖ нужен, когда проблема на стороне сервера 1С или СУБД, а замер в конфигураторе показывает только общее время без деталей. Настройка ТЖ выполняется через файл logcfg.xml, который размещается в каталоге conf сервера или клиента.
ЦУП (Центр управления производительностью) — отдельная конфигурация от фирмы «1С» для постоянного мониторинга. Она собирает показатели APDEX по ключевым операциям, строит графики и позволяет отслеживать деградацию производительности во времени. ЦУП оправдан для систем с десятками активных пользователей, где нужен не разовый замер, а непрерывный контроль.
Сравнение инструментов
Подходит для разового анализа конкретной операции по строкам кода. Требует доступа к конфигуратору и воспроизведения операции.
Нужен для анализа запросов к СУБД, блокировок и ошибок на сервере. Работает постоянно, но создаёт нагрузку на диск и требует отключения после диагностики.
Для постоянного мониторинга APDEX и трендов производительности в продуктивной базе. Требует развёртывания отдельной конфигурации и настройки.
Как сделать замер производительности в конфигураторе
Замер выполняется в режиме отладки. Последовательность такая: откройте конфигуратор, запустите отладку (меню «Отладка» → «Начать отладку»), затем в меню «Отладка» включите пункт «Замер производительности». После этого в клиентском приложении воспроизведите проблемную операцию — например, проведите документ или сформируйте отчёт.
Когда операция завершится, снова откройте меню «Отладка» → «Замер производительности» — флажок снимется, а результаты отобразятся в отдельном окне. Важно: замер фиксирует только то, что выполнялось, пока он был включён, поэтому включать его нужно непосредственно перед операцией, а выключать — сразу после. Иначе в таблицу попадёт лишний «шум» от фоновых действий.
- 1Откройте конфигуратор и запустите отладку нужного клиентского сеанса
- 2Включите «Отладка» → «Замер производительности»
- 3Воспроизведите медленную операцию один раз, без лишних действий
- 4Отключите замер тем же пунктом меню — откроется таблица результатов
- 5Отсортируйте по колонке «Время» и найдите строки с максимальной долей
- 6Раскройте строку-лидера и посмотрите, какой запрос или вызов занимает время
Для точности замер стоит повторить 2–3 раза подряд. Первый прогон часто медленнее из-за прогрева кэша СУБД и платформы; сравнивать «до» и «после» оптимизации корректно только при одинаковых условиях — та же база, те же данные, тот же режим (файловый или клиент-серверный).
Как читать таблицу результатов замера
Таблица замера содержит несколько ключевых колонок. «Модуль.Строка» указывает место в коде. «Время» — суммарное время выполнения строки в секундах. «Количество» — сколько раз строка выполнялась. «Время (%)» — доля строки в общем времени замера. Именно сортировка по проценту позволяет быстро увидеть главных «потребителей» времени.
Характерный признак проблемы — строка с умеренным временем, но огромным количеством вызовов. Например, запрос, выполняющийся 0,05 секунды, но вызванный 10 000 раз в цикле, даст 500 секунд суммарно. Такая картина почти всегда означает «запрос в цикле» — классическую ошибку, которую нужно исправлять выносом запроса за цикл и выборкой пакетом.
Отдельно смотрите на строки, относящиеся к запросам. Если большая часть времени сидит в одном запросе, проблема, скорее всего, в его тексте или в отсутствии индекса по полям отбора. Если время распределено равномерно по множеству строк клиентского модуля — возможно, узкое место в частом обмене клиент-сервер, и стоит переносить логику в серверную процедуру.
Как проверить результат замера
Нет строки, занимающей более половины времени без объективной причины
Одна строка или запрос даёт 50–90% времени — это и есть узкое место
Количество соответствует логике алгоритма (по одному вызову на объект)
Запрос вызывается тысячи раз — признак запроса в цикле
Время стабильно от прогона к прогону
Результаты скачут в разы — мешают фоновые процессы или блокировки
Замер на сервере: технологический журнал и запросы к СУБД
Если замер в конфигураторе показывает, что время уходит в запрос, но не объясняет почему, подключается технологический журнал. В файле logcfg.xml включаются события DBMSSQL (или DBPOSTGRS, DBORACLE — в зависимости от СУБД) с указанием порога длительности, например фиксировать только запросы длиннее 1 секунды. Это позволяет не тонуть в потоке мелких событий.
По событиям ТЖ видно полный текст запроса в том виде, в каком он ушёл на СУБД, и его длительность. Дальше запрос анализируется средствами самой СУБД: план выполнения в SQL Server Management Studio или pgAdmin покажет, используется ли индекс, есть ли сканирование таблицы целиком. Частая причина медленного запроса — отбор по невиртуальным полям большой таблицы без подходящего индекса или соединение с виртуальной таблицей без отборов.
Также в ТЖ полезны события блокировок (TLOCK, TDEADLOCK). Если пользователи жалуются не на равномерную медлительность, а на периодические «зависания» в часы пик, причина часто в ожиданиях на блокировках, а не в медленном коде. Замер производительности такую проблему покажет косвенно — увеличенным временем строк записи в базу.
ЦУП и APDEX: постоянный контроль производительности
Разовый замер отвечает на вопрос «почему медленно сейчас», но не показывает динамику. ЦУП решает задачу постоянного наблюдения: система собирает время выполнения ключевых операций (проведение документов, формирование отчётов, открытие форм) и рассчитывает показатель APDEX — интегральную оценку того, насколько фактическое время соответствует целевому.
Практический порядок работы с ЦУП: разворачивается отдельная база ЦУП, в исследуемой конфигурации настраивается отправка данных о ключевых операциях, задаются целевые времена для каждой операции. Далее администратор отслеживает дашборд: падение APDEX по конкретной операции — повод сделать точечный замер в конфигураторе и разобрать причину. Так ЦУП и замер работают в связке: один находит момент проблемы, другой — её причину.
Целевые времена стоит задавать реалистично, исходя из текущих замеров и ожиданий пользователей. Завышенные требования дадут постоянно «красный» APDEX без реальной проблемы, заниженные — скроют деградацию. Разумная практика — зафиксировать текущие значения как базовую линию и отслеживать отклонения от неё.
Типичные ошибки при замере и оптимизации
Отдельная ошибка — оптимизировать то, что занимает доли процента времени. Правило простое: сначала устраняется строка-лидер по доле времени, затем замер повторяется. Часто после исправления одного узкого места картина меняется, и следующий кандидат на оптимизацию оказывается другим, чем ожидалось.
Также не стоит забывать про клиентскую часть. Если замер серверного кода показывает приемлемое время, а пользователь всё равно ждёт, причина может быть в медленном канале связи, слабом клиентском компьютере или толстом клиенте с тяжёлыми формами. В таком случае смотрят на время открытия форм и объём передаваемых данных, а не только на серверный код.
Перед любой оптимизацией сохраните результаты исходного замера (таблицу можно вывести и сохранить). Без «замера до» невозможно доказать эффект от изменений и легко скатиться в бесконечную перестройку кода без измеримого результата.
Как проверить, что оптимизация сработала
Критерий успеха — повторный замер в тех же условиях. Та же база или её копия с идентичными данными, та же операция, тот же режим работы. Сравниваются общее время операции и профиль по строкам: строка, которая была лидером, должна исчезнуть из верхних позиций или сократиться кратно.
Если оптимизировался запрос, дополнительно проверяется план выполнения на СУБД: сканирование таблицы должно смениться поиском по индексу. Если устранялся запрос в цикле — количество вызовов в колонке «Количество» должно упасть с тысяч до единиц.
Финальная проверка — в продуктивной среде с наблюдением за реальными пользователями. Если используется ЦУП, эффект виден по росту APDEX соответствующей операции. Без этого шага есть риск, что оптимизация работала только на тестовых данных и на реальных объёмах эффект окажется скромнее.
Что важно запомнить
Замер делается через «Отладка → Замер производительности» в конфигураторе, анализ ведётся по колонкам «Время (%)» и «Количество». Запросы к СУБД разбираются через технологический журнал, постоянный контроль — через ЦУП и APDEX. Любая оптимизация начинается с замера «до» и заканчивается замером «после» в идентичных условиях.
Частые вопросы о замере производительности 1С
Можно ли сделать замер без конфигуратора и отладки?
Полноценный построчный замер требует конфигуратора. Без него доступны косвенные методы: технологический журнал на сервере, мониторинг запросов средствами СУБД и ЦУП, который собирает длительности ключевых операций в штатном режиме работы.
Почему результаты замера сильно отличаются от прогона к прогону?
Чаще всего влияют прогрев кэша СУБД, фоновые и регламентные задания, блокировки от других пользователей и нестабильная сеть. Для сопоставимых результатов замеряйте в изолированной копии базы, минимум два-три раза, и используйте медианное значение.
Что означает большое значение в колонке «Количество»?
Строка выполняется многократно — обычно внутри цикла. Если это запрос или обращение к базе, суммарное время будет большим даже при малом времени одного вызова. Решение — вынести запрос из цикла и получить данные одним пакетом с последующим поиском в выборке или соответствии.
Безопасно ли включать технологический журнал на продуктивном сервере?
Да, при соблюдении двух условий: настраивайте фильтры (только нужные события и порог длительности) и следите за свободным местом на диске с логами. После завершения диагностики настройки отключите — постоянная подробная запись создаёт лишнюю нагрузку и риск переполнения диска.
С чего начать, если медленно работает вся система, а не одна операция?
Начните с инфраструктуры: загрузка CPU, памяти и дисковой подсистемы сервера СУБД, наличие длительных запросов и блокировок в ТЖ. Если серверные ресурсы в норме — разверните ЦУП, чтобы увидеть, какие именно операции проседают по APDEX, и уже их замеряйте точечно в конфигураторе.
Нужно ли оптимизировать код, если замер показывает 2 секунды на операцию?
Зависит от контекста. Для разового отчёта 2 секунды — нормально, для массового проведения документов при тысячах операций в день — уже заметная потеря времени. Ориентируйтесь на частоту операции и ожидания пользователей, а не на абсолютное значение.