Как масштабировалась 1С:ЗУП КОРП под экстремальной нагрузкой

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

Именно такой сценарий был воспроизведён нашими экспертами при нагрузочном тестировании (НТ) «1С:Зарплата и управление персоналом 8 КОРП» редакции 3.1. В рамках испытаний система выполнила 40 000 перерасчётов и расчёт заработной платы на массиве из 30 000 табельных номеров.

Тестирование проводила компания «ИТ-Экспертиза». Перед специалистами стояли две задачи, которые беспокоили заказчика больше всего:

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

Особенность теста: не виртуальные клики, а тяжёлый расчётный сценарий

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

Тестовый сценарий включал:

• перерасчёт отпусков по 10 000 табельных номеров (ТН);
• перерасчёт командировок по 10 000 табельных номеров после выплаты годовой премии;
• перерасчёт заработной платы по 20 000 табельных номеров вследствие корректировки табеля за предыдущие месяцы;
• расчёт заработной платы по 30 000 табельных номеров.

Таким образом, проверялась производительность не отдельных транзакций, а законченного расчётного цикла, создающего длительную и неоднородную нагрузку на серверы «1С:Предприятия» и СУБД. Для 1С:ЗУП КОРП это более показательный сценарий, чем синтетическая генерация большого количества простых пользовательских действий.

Программный контур

Испытания проводились на следующем стеке:

• «1С:Зарплата и управление персоналом 8 КОРП», редакция 3.1. Точная версия конфигурации: 3.1.36.45;
• Платформа «1С:Предприятие 8.3» версии 8.3.27.1786;
• Postgres Pro 17.4;
• Astra Linux 1.7 на виртуальных машинах;
• Proxmox в качестве гипервизора;
• Apache;
• NVMe-накопители.

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

Два стенда с разной серверной архитектурой

Стенд № 1

Сервер СУБД был построен на Intel Xeon Platinum 8260:

В контуре также использовались три сервера «1С:Предприятия» и Apache. Для каждого было выделено 64 ядра, включая виртуальные, и 128 ГБ оперативной памяти.

Стенд № 2

Во втором контуре сервер СУБД был переведён на AMD EPYC 9555:

Количество серверов «1С:Предприятия» осталось прежним: три сервера по 64 ядра и 128 ГБ оперативной памяти. Новая инфраструктура использовала память DDR5, а увеличение ресурсов сервера СУБД позволило расширить число одновременно выполняемых потоков до 256.

Результат на первом стенде: 5 122 секунды

Для полного сценария было установлено целевое время 7 200 секунд, то есть два часа.

На конфигурации с Intel Xeon Platinum 8260 операции выполнялись следующим образом:

Полное время ключевой операции составило 5 122 секунды, или 1 час 25 минут 22 секунды. Таким образом, исходный стенд выполнил расчётный цикл в пределах установленного двухчасового интервала.

Зафиксированное значение APDEX для контрольной операции составило 1,000. В рамках данного теста выполнялся один замер, поэтому минимальное, среднее и максимальное значения совпадают.

Рисунок 1. Загрузка процессоров серверов «1С:Предприятия» при выполнении теста на стенде № 1

Рисунок 2. Загрузка процессоров сервера Postgres Pro при выполнении теста на стенде № 1

Результат на втором стенде: 2 626 секунд

После переноса сценария на инфраструктуру с AMD EPYC 9555 были получены следующие результаты:

Полный цикл занял 2 626 секунд, или 43 минуты 46 секунд.

При неизменном составе операций время выполнения сократилось с 5 122 до 2 626 секунд, то есть практически в два раза. Целевой предел в 7 200 секунд был достигнут на обоих стендах, однако второй контур продемонстрировал существенный запас по времени выполнения массовых перерасчётов.

Значение APDEX для контрольной операции также составило 1,000 при одном выполненном замере.

Рисунок 3. Загрузка процессоров серверов «1С:Предприятия» при выполнении теста на стенде № 2

Рисунок 4. Загрузка процессоров сервера Postgres Pro при выполнении теста на стенде № 2

Где был получен основной выигрыш

Наиболее заметно смена инфраструктуры повлияла на продолжительные операции перерасчёта документов:

• перерасчёт отпусков сократился с 2 343 до 1 125 секунд;
• перерасчёт командировок сократился с 1 951 до 923 секунд;
• расчёт доначислений сократился с 651 до 428 секунд;
• расчёт заработной платы сократился со 175 до 148 секунд.

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

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

Почему этот результат важен для крупных внедрений 1С:ЗУП КОРП

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

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

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

Для проектов 1С такой результат особенно показателен. Он демонстрирует, что при оценке производительности 1С:ЗУП КОРП недостаточно измерять отдельные операции или ориентироваться только на число пользователей. Критичным объектом тестирования должен быть полный расчётный процесс: с реальными объёмами кадровых данных, массовыми перерасчётами и последовательностью операций, соответствующей промышленной эксплуатации.