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

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

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

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

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

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

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

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

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

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

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

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

Выберите инструменты нагрузочного тестирования

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

Сравнение инструментов

Тест-центр (из комплекта КИП)

Штатный инструмент фирмы «1С» для автоматизированного многопользовательского тестирования. Подходит для типовых конфигураций, требует настройки сценариев и отдельных клиентских машин.

Сценарное тестирование через Vanessa Automation / ADD

Гибкие open-source решения для автоматизации действий в клиенте 1С. Подходят как для функциональных, так и для нагрузочных проверок, но требуют навыков разработки сценариев.

Эмуляция нагрузки фоновыми заданиями и COM/HTTP-запросами

Простой способ нагрузить сервер без клиентских лицензий: пакетное проведение документов, массовые вызовы веб-сервисов. Не воспроизводит поведение интерактивных пользователей.

JMeter и аналогичные генераторы нагрузки

Применимы для тестирования HTTP- и web-сервисов, публикуемых 1С. Не подходят для эмуляции тонкого клиента без дополнительной разработки.

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

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

Соберите метрики: что и чем измерять

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

Со стороны 1С ключевой источник — технологический журнал: события DBMSSQL/DBPOSTGRS (длительность запросов), TLOCK и TDEADLOCK (блокировки и взаимоблокировки), EXCP (исключения), CALL и SCALL (длительность вызовов). Настройте logcfg.xml так, чтобы фиксировать события длительнее заданного порога, иначе объём логов станет неуправляемым.

Со стороны СУБД отслеживайте длительность запросов, ожидания (waits), число взаимоблокировок, утилизацию tempdb и размер лога транзакций. На уровне операционной системы смотрите загрузку процессора, очередь диска, свободную память и сетевую задержку между сервером 1С и сервером СУБД.

Выполните тесты: от калибровки до пиковой нагрузки

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

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

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

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

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

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

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

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

Как проверить результат

Время отклика при целевой нагрузке

Норма

Укладывается в целевые показатели, 95-й перцентиль стабилен

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

Растёт скачками, появляются длинные «хвосты» распределения

Ошибки и исключения

Норма

Отсутствуют или единичны и объяснимы

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

Взаимоблокировки, таймауты, обрывы сеансов

Утилизация ресурсов

Норма

Есть запас по CPU, памяти и дискам на пиковой ступени

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

Один из ресурсов утилизирован почти полностью

Повторяемость

Норма

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

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

Результаты сильно различаются между прогонами без причины

После анализа вносите изменения по одному и перепроверяйте: только так можно достоверно связать эффект с конкретной правкой. Параллельное изменение настроек СУБД, кода и «железа» делает выводы недоказуемыми.

Типичные ошибки и ограничения самостоятельного тестирования

У самостоятельного тестирования есть естественные ограничения. Эмуляция сотен интерактивных пользователей требует парка клиентских машин и лицензий; упрощённые сценарии через серверные вызовы не воспроизводят реальное поведение людей. Для крупных внедрений с сотнями одновременных пользователей имеет смысл привлекать специалистов с опытом нагрузочных проектов и готовыми методиками.

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

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

Можно ли тестировать производительность прямо на рабочем сервере в нерабочее время?

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

Сколько виртуальных пользователей может держать одна клиентская машина при тесте Тест-центром?

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

Какие события технологического журнала включать в первую очередь?

Минимальный рабочий набор: события длительных вызовов СУБД (DBMSSQL или аналог для вашей СУБД) с порогом длительности, TLOCK и TDEADLOCK для блокировок, EXCP для исключений, а также CALL/SCALL для оценки длительности серверных вызовов. Включайте события с порогами по длительности, иначе объём журнала быстро станет необозримым и сам нагрузит дисковую подсистему.

Тест показал рост времени отклика, но процессор и диски недогружены. Что это значит?

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

Нужно ли тестировать файловую базу 1С?

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

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

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