Администрирование · 12 мин
Как протестировать производительность 1С
Как протестировать производительность 1С: замеры времени операций, APDEX, нагрузочное тестирование, анализ запросов и блокировок. Практическое руководство для администраторов.
Медленная работа 1С — одна из самых частых жалоб пользователей, но «тормозит» — не диагноз. Прежде чем менять сервер, оптимизировать код или увеличивать память, нужно измерить производительность: понять, какие операции занимают время, где узкое место — в СУБД, сервере 1С, сети или клиенте. Без объективных замеров любая оптимизация превращается в гадание, а деньги на «железо» тратятся впустую.
Тестирование производительности 1С делится на два больших направления: оценка текущего состояния системы (сколько времени занимают типовые операции сейчас) и нагрузочное тестирование (как система поведёт себя при росте числа пользователей или объёма данных). Для первого достаточно штатных инструментов платформы, для второго нужны специализированные средства вроде 1С:Центр администрирования, конфигурации «Тест-центр» из 1С:КИП или внешних нагрузочных решений.
Материал рассчитан на администраторов и разработчиков 1С, которые работают с клиент-серверными базами. Часть приёмов применима и к файловым базам, но именно клиент-серверная архитектура даёт наибольшее число точек для замера и оптимизации.
Что именно нужно измерять: ключевые метрики
Производительность 1С нельзя описать одним числом. Практически значимы несколько метрик: время выполнения критичных операций (проведение документа, формирование отчёта, закрытие месяца), время отклика интерфейса у пользователя, длительность запросов к СУБД, число и длительность блокировок, загрузка ресурсов серверов (CPU, память, дисковая подсистема).
Для агрегированной оценки удобно использовать показатель APDEX (Application Performance Index) — он переводит время отклика операций в индекс от 0 до 1 с учётом целевого времени T. Операции быстрее T считаются удовлетворительными, медленнее 4T — неприемлемыми. APDEX поддерживается штатными механизмами оценки производительности в типовых конфигурациях на базе БСП (подсистема «Оценка производительности»).
Важно с самого начала зафиксировать целевые значения. Например: проведение документа реализации — не более 2 секунд, открытие списка заказов — не более 1 секунды, отчёт по продажам за месяц — не более 30 секунд. Без целевых значений невозможно отличить проблему от ожиданий пользователей, завышенных по отношению к реальным возможностям системы.
Подготовка: базовая линия и тестовый стенд
Первый шаг любого тестирования — снять «базовую линию»: замерить ключевые операции на текущей системе в типичных условиях. Выберите 5–10 самых массовых и самых тяжёлых операций, замерьте каждую несколько раз в разное время суток и зафиксируйте результаты. Эти цифры станут точкой отсчёта: после любых изменений вы сможете объективно сказать, стало лучше или хуже.
Нагрузочные тесты и эксперименты с настройками проводите только на копии базы. Тестовый стенд должен быть максимально похож на рабочую среду: та же версия платформы и СУБД, сопоставимый объём данных, аналогичные параметры серверов. Тесты на базе в 10 раз меньше рабочей дадут результаты, неприменимые к реальности — многие проблемы (например, деградация планов запросов или эскалации блокировок) проявляются только на больших объёмах.
Замеры штатными средствами платформы
Замер производительности в конфигураторе
Встроенный инструмент «Замер производительности» (Отладка → Замер производительности) показывает, сколько времени заняла каждая строка кода и какие запросы выполнялись. Это основной инструмент, когда уже известна конкретная медленная операция: запускаете замер, воспроизводите операцию, останавливаете — и видите, какие строки модуля и какие запросы съели время.
Обращайте внимание не только на суммарное время, но и на количество вызовов. Классическая проблема — запрос в цикле: один запрос выполняется быстро, но вызывается тысячи раз. В замере это видно как строка с огромным числом вызовов при малом времени каждого.
Технологический журнал
Технологический журнал (ТЖ) — механизм логирования событий платформы: запросы к СУБД (DBMSSQL, DBPOSTGRS, DBORACLE), блокировки (TLOCK, TTIMEOUT, TDEADLOCK), вызовы кластера, длительные транзакции. Настраивается файлом logcfg.xml, который размещается в каталоге conf сервера 1С.
Для поиска узких мест настройте фильтр на длительные события: например, запросы дольше 1 секунды и все взаимоблокировки. Собранные логи удобно разбирать через 1С:ЦЭККМ или парсеры ТЖ. Технологический журнал отвечает на вопрос «что именно медленно работает на сервере», даже когда проблему нельзя воспроизвести по команде — события пишутся в фоне.
<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1clogs" history="24"><event><eq property="name" value="DBMSSQL"/></event><event><eq property="name" value="TDEADLOCK"/></event><property name="all"/></log></config>Нагрузочное тестирование
Нагрузочное тестирование отвечает на вопрос: выдержит ли система рост нагрузки — например, увеличение числа пользователей с 50 до 200 или сезонный пик продаж. Смысл метода: программно эмулируется работа множества пользователей, выполняющих типовые сценарии, и измеряется время отклика и потребление ресурсов под нагрузкой.
Штатный инструмент — «Тест-центр» из комплекта 1С:КИП (Корпоративный инструментальный пакет). Он позволяет описать сценарии действий пользователей, запустить их параллельно с нескольких рабочих станций и получить отчёт по времени операций и APDEX. Альтернативы — решения на базе нагрузочных фреймворков (например, сценарии через внешние инструменты тестирования, управляющие клиентом 1С) или самописные обработки, массово выполняющие операции через COM/веб-сервисы.
Методика теста: определите 3–5 типовых сценариев (оформление заказа, проведение реализации, формирование отчёта), задайте профиль нагрузки (сколько виртуальных пользователей выполняет каждый сценарий и с какой интенсивностью), прогоните тест на 30–60 минут, постепенно увеличивая нагрузку. Фиксируйте, при каком числе пользователей время отклика начинает деградировать — это и есть предел системы в текущей конфигурации.
- 1Разверните копию рабочей базы на тестовом стенде с сопоставимым объёмом данных
- 2Определите 3–5 типовых сценариев и целевые времена операций
- 3Настройте сценарии в «Тест-центре» или другом инструменте
- 4Запустите тест, постепенно увеличивая число виртуальных пользователей
- 5Параллельно собирайте счётчики ОС и СУБД: CPU, память, диск, ожидания
- 6Зафиксируйте точку деградации и сопоставьте её с загрузкой ресурсов
Анализ узких мест: СУБД, сервер 1С, код
Результаты замеров нужно увязать с загрузкой ресурсов. Если время операций растёт при высокой загрузке дисковой подсистемы сервера СУБД — проблема в дисках или запросах, читающих много данных. Если CPU сервера СУБД загружен на 100%, а диски свободны — вероятны неоптимальные планы запросов и сканирования таблиц. Если сервер СУБД простаивает, а сервер 1С загружен — узкое место в коде конфигурации или нехватке рабочих процессов.
Для MS SQL Server и PostgreSQL полезны штатные средства: планы выполнения запросов, статистика ожиданий, динамические представления. Запрос из технологического журнала можно взять в студию управления СУБД и посмотреть план: полные сканирования больших таблиц там, где ожидался поиск по индексу, — прямое указание на необходимость индекса или переписывания запроса.
Отдельный класс проблем — блокировки. Взаимоблокировки (TDEADLOCK) и длительные ожидания на блокировках видны в технологическом журнале. Типичные причины: длинные транзакции, проведение больших документов, конкуренция за итоги регистров. Часто помогает включение управляемого режима блокировок, разделение данных по времени (сдвиг документов на разные секунды) и сокращение транзакций.
Как выбрать действие
Типичные ошибки при тестировании
Самая частая ошибка — тестирование на непредставительных данных. База в десять раз меньше рабочей не покажет проблем с планами запросов и блокировками. Вторая ошибка — одноразовый замер: время одной операции сильно зависит от кэша СУБД, поэтому замеряйте несколько раз и смотрите и «холодный», и «тёплый» результат.
Третья ошибка — оптимизация без замера. Администраторы нередко добавляют память или меняют настройки кластера «на глаз», а потом не могут доказать эффект. Любое изменение должно сопровождаться повторным замером тех же операций в тех же условиях. Наконец, многие забывают выключить подробный технологический журнал после диагностики — детальное логирование само по себе замедляет систему.
Контроль результата и регулярный мониторинг
После оптимизации повторите исходные замеры и сравните с базовой линией. Результат считается достигнутым, если целевые операции уложились в заданные времена при типичной нагрузке, а нагрузочный тест показывает запас по числу пользователей. Разовое ускорение не гарантирует стабильности: с ростом базы производительность будет постепенно деградировать.
Поэтому тестирование стоит сделать регулярным: включите постоянный сбор APDEX, настройте мониторинг ключевых счётчиков серверов и периодически (например, раз в квартал или после обновлений конфигурации) повторяйте контрольные замеры. Это позволит заметить деградацию до того, как она станет жалобами пользователей.
Как проверить результат
Операции укладываются в целевые времена при типовой нагрузке
Время выросло после обновления или роста базы
Индекс стабильно выше 0,85
Падение ниже 0,7, рост доли неприемлемых операций
Единичные таймауты, нет взаимоблокировок
Регулярные TDEADLOCK и массовые TTIMEOUT
CPU и диски имеют запас при пиковой нагрузке
Один из ресурсов загружен на 90–100%
Что важно запомнить
Сначала измеряйте, потом оптимизируйте: зафиксируйте базовую линию, найдите узкое место через технологический журнал и счётчики ресурсов, проверяйте эффект повторными замерами. Нагрузочные тесты — только на копии базы, а мониторинг производительности должен стать постоянным процессом, а не разовой акцией.
Частые вопросы
Можно ли тестировать производительность файловой базы 1С?
Да, но инструментарий ограничен: доступен замер производительности в конфигураторе и технологический журнал, а вот анализ на уровне СУБД невозможен. Файловый режим сам по себе является ограничением: при росте числа пользователей и объёма данных рекомендуется переход на клиент-серверный вариант, где диагностика значительно богаче.
Что такое 1С:КИП и обязателен ли он для нагрузочного тестирования?
1С:КИП (Корпоративный инструментальный пакет) — отдельный программный продукт фирмы «1С», в который входит «Тест-центр» для нагрузочного тестирования и «Центр администрирования». Для простых задач можно обойтись без него: самописные обработки, массово выполняющие операции, или внешние инструменты тестирования тоже дают нагрузку, но «Тест-центр» удобнее для воспроизводимых многосценарных тестов.
Как понять, что проблема в «железе», а не в коде конфигурации?
Сопоставьте замеры с загрузкой ресурсов. Если под нагрузкой диски или CPU сервера СУБД загружены полностью, а запросы в технологическом журнале по отдельности выполняются быстро — вероятно, ресурсов не хватает. Если же конкретные запросы медленные даже без нагрузки и в планах видны сканирования больших таблиц — проблема в коде и структуре данных, и апгрейд сервера даст лишь временный эффект.
Насколько безопасно включать технологический журнал на рабочем сервере?
Лёгкий фильтр (только длительные запросы и взаимоблокировки) нагружает систему незначительно и допустим на рабочем сервере. Детальный журнал со всеми событиями создаёт большой объём записи на диск и может замедлить систему — включайте его на короткое время и следите за свободным местом, чтобы логи не заполнили диск.
Как часто нужно повторять тестирование производительности?
Обязательные точки: после обновления конфигурации или платформы, после значительного роста объёма данных или числа пользователей, после изменений в оборудовании. В остальное время достаточно постоянного мониторинга APDEX и счётчиков ресурсов — он покажет момент, когда потребуется внеплановое расследование.
Что делать, если пользователи жалуются на «тормоза», а замеры показывают норму?
Проверьте участки вне сервера: сеть между клиентом и сервером, терминальную инфраструктуру, антивирус на клиентских машинах, скорость диска на рабочем месте для файловых баз. Замерьте время операции непосредственно на сервере и на проблемном рабочем месте — разница укажет на клиентский или сетевой сегмент.