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

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

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

Материал ориентирован на администраторов и разработчиков 1С, работающих с клиент-серверными базами. Рассмотрены встроенные средства платформы, замер через эталонную обработку, сбор счётчиков на сервере и типовые ошибки, которые искажают результаты тестирования.

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

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

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

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

Быстрый замер эталонной обработкой

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

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

1. 1
   Зафиксируйте конфигурацию: версии платформы и СУБД, параметры сервера, размер базы.
2. 2
   Запустите эталонную обработку оценки производительности в монопольном режиме, выполните 3–5 прогонов и усредните результат.
3. 3
   Повторите замер под типовой пользовательской нагрузкой и сравните с монопольным результатом.
4. 4
   Сохраните результаты как базовую точку отсчёта для будущих сравнений.

Инструменты платформы: замер производительности и технологический журнал

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

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

<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1c_logs" history="24"><event><eq property="name" value="DBMSSQL"/></event><event><eq property="name" value="TLOCK"/></event><event><eq property="name" value="TDEADLOCK"/></event><property name="all"/></log></config>

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

Диагностика на стороне СУБД и сервера

Большая часть времени выполнения тяжёлых операций 1С уходит на запросы к СУБД, поэтому сервер баз данных нужно наблюдать отдельно. Для MS SQL Server используйте динамические административные представления (sys.dm_exec_query_stats, sys.dm_os_wait_stats) и расширенные события; для PostgreSQL — pg_stat_statements и журнал медленных запросов. Ищите запросы с максимальным суммарным временем, полными сканированиями таблиц и частыми перекомпиляциями.

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

Нагрузочное тестирование и ЦУП

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

Методика такова: выбирают 5–10 ключевых операций, для каждой задают целевое время, записывают сценарии и прогоняют их с нарастающим числом виртуальных пользователей. По результатам строят зависимость времени операций от нагрузки и находят точку деградации. Тестирование выполняйте на копии рабочей базы с реалистичным объёмом данных — результаты на пустой базе ничего не скажут о реальной системе.

Интерпретация результатов и типичные ошибки

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

Вторая ошибка — оптимизация не того звена. Администраторы увеличивают память серверу, когда проблема в запросе без индекса, а разработчики переписывают код, когда узкое место — диск с журналом транзакций. Прежде чем что-то менять, локализуйте проблему замером: клиент, сервер 1С или СУБД. Третья ошибка — отсутствие базовой точки отсчёта: без зафиксированных показателей «до» невозможно доказать, что оптимизация сработала.

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

Частые вопросы