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

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

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

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

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

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

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

Для оценки качества работы пользователей удобен показатель APDEX (Application Performance Index). Он переводит время отклика операций в число от 0 до 1: значение ближе к 1 означает, что большинство операций выполняются быстро, ближе к 0 — пользователи массово испытывают задержки. В платформе 1С есть штатная подсистема оценки производительности, которая собирает замеры и рассчитывает APDEX по целевым операциям.

Быстрая диагностика: где именно теряется время

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

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

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

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

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

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

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

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

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

Типовой сценарий — включить запись событий DBMSSQL или DBPOSTGRS с фильтром по длительности, чтобы видеть все запросы, выполнявшиеся дольше заданного порога. Это позволяет собрать статистику тяжёлых запросов за рабочий день без вмешательства в работу пользователей. Учтите: подробный технологический журнал создаёт большой объём файлов и сам немного нагружает диск, поэтому собирайте только нужные события и ограничивайте глубину хранения.

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

Счётчики операционной системы и СУБД

Даже идеальный код будет медленным, если серверу не хватает ресурсов. На сервере СУБД и сервере 1С отслеживайте базовый набор счётчиков: загрузку процессора, доступную память, среднюю длину дисковой очереди и время отклика дисков, сетевую активность. В Windows для этого используют Performance Monitor (perfmon), в Linux — iostat, vmstat, top и аналогичные утилиты.

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

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

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

Как проверить серверные ресурсы

Дисковая очередь в часы пик

Норма

Близка к нулю или кратковременные всплески

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

Стабильно выше 1–2 на физический диск

Свободная оперативная память

Норма

Есть запас, файл подкачки почти не используется

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

Память исчерпана, активный свопинг

Загрузка процессора

Норма

В пике остаётся запас, нет длительного 100%

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

Длительные периоды загрузки 90–100%

Ожидания в СУБД

Норма

Преобладают короткие ожидания ввода-вывода

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

Доминируют ожидания блокировок и защёлок

Нагрузочное тестирование и оценка под нагрузкой

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

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

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

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

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

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

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

С чего начать, если пользователи просто жалуются, что «всё тормозит»?

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

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

Да. Администратор без прав разработчика может использовать технологический журнал, журнал регистрации с долгими вызовами, счётчики ОС и средства диагностики СУБД, а также штатную подсистему оценки производительности (APDEX), если она включена в конфигурации.

Как понять, что проблема именно в блокировках, а не в медленном железе?

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

Насколько достоверен замер на тестовой копии базы?

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

Как часто нужно контролировать производительность?

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