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

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

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

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

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

Что должно показать нагрузочное тестирование сервера 1С

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

Результат должен отвечать на несколько практических вопросов:

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

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

Обратная ситуация тоже возможна: CPU загружен умеренно, но пользователи ждут ответа из-за медленного диска, блокировки в СУБД, неоптимального запроса или ожидания внешней интеграции.

Проверка запуска и нагрузочное испытание — не одно и то же

После восстановления базы администратор обычно проверяет, что:

• база открывается;
• пользователи могут войти;
• формы и справочники доступны;
• документы записываются;
• отчёты запускаются;
• расширения и внешние компоненты загружаются.

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

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

Почему нельзя считать пользователей без учёта операций

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

На результат также влияют:

• прикладная конфигурация;
• объём и структура информационной базы;
• количество расширений;
• доработки и внешние обработки;
• используемая СУБД;
• клиентское или серверное выполнение кода;
• регламентные задания;
• обмены с другими системами;
• антивирусная проверка;
• производительность дисков и сети.

Поэтому формула «определённое количество пользователей на одно ядро» не может служить надёжным критерием приёмки.

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

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

Используйте копию рабочей информационной базы

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

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

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

Копия должна быть изолирована от рабочей базы. Пользователи и фоновые процессы не должны случайно изменить реальные данные.

Отключите внешние действия

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

Перед запуском испытания нужно проверить:

• обмены между информационными базами;
• интеграцию с CRM и сайтом;
• банковские сервисы;
• электронный документооборот;
• электронную почту и SMS;
• маркетплейсы;
• службы доставки;
• API внешних систем;
• торговое оборудование;
• регламентные задания с внешними действиями.

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

Обезличьте данные при необходимости

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

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

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

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

Зафиксируйте конфигурацию среды

До начала испытания запишите:

• версию платформы 1С;
• версию прикладной конфигурации;
• список расширений;
• версию и редакцию СУБД;
• параметры виртуального или физического сервера;
• количество виртуальных процессоров;
• объём RAM;
• тип и размер дисков;
• расположение сервера 1С и СУБД;
• параметры сети между узлами;
• число рабочих процессов кластера;
• основные настройки СУБД;
• установленное защитное и резервное ПО.

Без этого результаты будет трудно воспроизвести. Если после первого испытания изменить несколько параметров одновременно, станет непонятно, что именно повлияло на производительность.

Проверьте сопоставимость будущей среды

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

Перед тестом полезно заполнить чек-лист:

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

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

Его лучше строить не по должностям из штатного расписания, а по фактическим действиям в 1С.

Выберите реальные пользовательские операции

Для начала определите наиболее важные и тяжёлые операции:

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

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

Разделите пользователей по ролям

У разных сотрудников нагрузка отличается. Например:

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

После этого для каждой роли определяют количество одновременных сеансов и частоту операций.

Добавьте фоновые и регламентные задания

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

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

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

Подготовьте обычный и пиковый сценарии

Минимальный набор включает два режима:

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

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

Пример профиля:

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

Как проводить нагрузочное испытание

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

Зафиксируйте исходное состояние

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

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

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

Выполните прогрев

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

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

Увеличивайте нагрузку поэтапно

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

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

На каждом этапе нужно дать системе поработать достаточно долго, чтобы увидеть не только кратковременный скачок, но и накопление очередей, памяти, блокировок и дисковой активности.

Если увеличить нагрузку сразу до максимума, будет сложнее определить момент, на котором система перестала соответствовать требованиям.

Не меняйте несколько параметров одновременно

Если тест показал неудовлетворительный результат, изменения нужно вносить последовательно. Например:

1. Скорректировать настройку СУБД.
2. Повторить сценарий.
3. Изменить число рабочих процессов.
4. Снова повторить сценарий.
5. Увеличить RAM.
6. Провести следующий замер.

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

Повторяйте одинаковый сценарий

Для сравнения конфигураций должны совпадать:

• копия базы;
• число сеансов;
• набор операций;
• длительность этапов;
• расписание фоновых заданий;
• состояние кешей;
• порядок действий;
• способ сбора метрик.

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

Какие метрики собирать

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

Поэтому измерения нужно собирать одновременно.

Метрики операционной системы и сервера

Для сервера 1С и узла СУБД контролируют:

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

Среднее значение может скрывать короткие пики. Поэтому показатели нужно сопоставлять со временем выполнения конкретной операции.

Например, если отчёт замедлился в тот же момент, когда выросла задержка записи на диск, это полезнее, чем средняя загрузка диска за всё испытание.

Метрики СУБД

Для Microsoft SQL Server, PostgreSQL или другой используемой СУБД оценивают:

• длительность запросов;
• число активных соединений;
• ожидания;
• блокировки;
• взаимные блокировки;
• использование памяти;
• чтение и запись;
• активность временных данных;
• рост файлов базы и журнала;
• ошибки;
• запросы с наибольшим потреблением ресурсов.

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

Тест должен показать не только наличие блокировок, но и то, какая операция их создаёт, сколько они продолжаются и как влияют на пользователей.

Метрики сервера 1С

На уровне кластера 1С полезно наблюдать за:

• количеством сеансов;
• рабочими процессами;
• распределением нагрузки;
• потреблением памяти;
• длительными серверными вызовами;
• фоновыми заданиями;
• ошибками рабочих процессов;
• перезапусками;
• технологическим журналом;
• очередями и ожиданиями.

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

Время бизнес-операций

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

• входом в базу;
• открытием формы;
• поиском;
• записью документа;
• проведением;
• построением отчёта;
• выполнением обработки;
• завершением обмена;
• закрытием периода.

Именно эти значения позволяют сформулировать критерии приёмки понятным для бизнеса языком.

Удобно вести единую таблицу:

Как сформулировать критерии приёмки

Критерии определяют до испытания. Если сначала выполнить тест, а затем решить, какой результат считать хорошим, оценка станет субъективной.

Используйте измеримые требования

Для каждой важной операции фиксируют:

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

Пример таблицы приёмки:

Конкретное допустимое время определяет компания. Для одного процесса задержка в несколько минут приемлема, а для другого даже несколько секунд нарушают работу сотрудников.

Оценивайте стабильность, а не только скорость

Система может быстро пройти короткий тест и начать деградировать при длительной работе. Поэтому нужно проверить:

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

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

Разделяйте три возможных решения

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

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

Требуется усиление или изменение архитектуры. После проверки и настройки сохраняется измеримое ограничение CPU, RAM, диска, сети либо отдельного компонента. В этом случае увеличивают ресурсы или разделяют роли сервера 1С, СУБД и терминального доступа.

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

Учитывайте ограничения синтетических результатов

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

Кроме того, после переноса могут измениться:

• объём базы;
• расписание заданий;
• версии платформы и конфигурации;
• состав расширений;
• интеграции;
• число пользователей;
• сетевые маршруты;
• антивирусные политики.

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

Заключение

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

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

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

Что почитать дальше

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

Когда стоит обратиться к специалистам

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

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

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

Кратко

• Запуск базы в одном сеансе не подтверждает готовность сервера к рабочей нагрузке.
• Производительность 1С нельзя надёжно оценить только по числу пользователей.
• Тест проводят на изолированной копии базы с отключёнными рабочими интеграциями.
• Сценарии должны воспроизводить реальные операции и фоновые задания.
• Нагрузку увеличивают поэтапно, фиксируя состояние системы на каждом уровне.
• Метрики сервера, СУБД и 1С нужно сопоставлять со временем бизнес-операций.
• Критерии приёмки определяют до начала испытания.
• Успешный тест снижает риск переноса, но не отменяет мониторинг после запуска.