Как провести нагрузочное тестирование 1С

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

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

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

Определите цели и критерии успешности теста

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

Определите профиль нагрузки — сколько пользователей каждой роли работает одновременно. Реальный профиль почти никогда не равен общему числу учётных записей: из 200 сотрудников одновременно активно работают обычно 60–70%, а интенсивно вводят документы ещё меньше. Разделите пользователей на группы: менеджеры по продажам, кладовщики, бухгалтеры, руководители с отчётами — у каждой группы свои сценарии и своя интенсивность.

Учтите пиковые периоды. Если обычная нагрузка — 80 пользователей, а в день закрытия месяца — 150 с массовым проведением документов, тестировать нужно именно пик, иначе результаты не отразят реальную картину. Критерии успеха запишите в виде: «при N одновременных пользователях доля операций, уложившихся в целевое время, — не менее 95%, ошибок блокировок — не более заданного процента».

Подготовьте изолированный тестовый стенд

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

Стенд должен быть максимально похож на продуктивную среду: та же версия платформы 1С, та же СУБД (MS SQL, PostgreSQL) и её версия, сопоставимые объёмы оперативной памяти и характеристики дисковой подсистемы. Если тестировать на сервере вдвое слабее продуктивного, вы получите пессимистичные результаты; если на более мощном — пропустите реальные проблемы. Там, где точное соответствие невозможно, фиксируйте расхождения и учитывайте их при интерпретации.

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

Выберите инструменты для тестирования

Штатный инструмент вендора — «1С:Тест центр» из комплекта 1С:КИП (корпоративный инструментальный пакет). Он позволяет записывать сценарии действий пользователей, параметризовать их и воспроизводить в десятках параллельных сеансов, собирая статистику по времени выполнения операций. Для большинства типовых задач этого достаточно, а интеграция с платформой упрощает настройку.

Альтернативный подход — внешние нагрузочные инструменты общего назначения (например, JMeter) для тестирования web-клиента и HTTP-сервисов, а также тестирование на уровне СУБД: воспроизведение тяжёлых запросов через план обслуживания и замеры. Такой вариант подходит, когда нужно проверить узкий участок — например, производительность конкретного запроса или интеграционного API, а не поведение пользовательского интерфейса.

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

Напишите и параметризуйте сценарии

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

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

Добавьте в сценарии паузы (think time) — реальный пользователь не вводит документ за доли секунды, а думает, ищет данные, переключается между окнами. Сценарий без пауз создаёт нагрузку, в разы превышающую реальную, и тест покажет проблемы там, где их нет. Типичная интенсивность — один документ в несколько минут на активного пользователя, но ориентируйтесь на замеры в реальной системе.

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

Проведите тест и соберите метрики

Начинайте с малого: 5–10 виртуальных пользователей, затем ступенчато увеличивайте нагрузку — 25, 50, 100 и далее до целевого уровня. Ступенчатый рост позволяет увидеть точку перегиба — момент, когда время отклика начинает расти непропорционально. Резкий старт сразу с сотни сеансов затрудняет диагностику: непонятно, на каком уровне система «сломалась».

Во время прогона фиксируйте: время выполнения каждой ключевой операции (среднее и, что важнее, 90–95-й перцентиль), количество ошибок и отказов, число взаимоблокировок и превышений ожидания блокировок, загрузку CPU, память и дисковую очередь на сервере 1С и сервере СУБД. Один длительный прогон на целевой нагрузке (1–2 часа) информативнее десяти пятиминутных: часть проблем — утечки памяти, рост tempdb — проявляется только со временем.

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

<event><eq property="name" value="DBMSSQL"/></event><event><eq property="name" value="TLOCK"/></event><event><eq property="name" value="TDEADLOCK"/></event><property name="duration"><eq value="1000000"/></property>

Проанализируйте результаты и устраните узкие места

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

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

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

Типичные ошибки и ограничения методики

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

Учитывайте и ограничения самой методики. Нагрузочный тест показывает поведение системы на заложенном профиле нагрузки — если реальные пользователи начнут работать иначе (например, массово формировать отчёты, которые в тест не входили), прогноз не сработает. Поэтому профиль нагрузки стоит пересматривать после каждого существенного изменения бизнес-процессов.

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