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

Кстати, приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск, где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. 

Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей. 

Регистрация здесь

Когда привычные подходы не работают

Мы в Beeline Cloud активно развиваем облачные решения, и наш отдел эксплуатации платформы 1С это тоже не обошло стороной. У нас есть несколько географически распределенных ЦОДов с разным железом под слоем виртуализации. Когда начали предоставлять IaaS для 1С-приложений, встал вопрос: какой ЦОД и оборудование лучше подойдут под специфику платформы?

На первый взгляд все просто — берем проверенный тест Гилева, который десятилетиями используется в 1С-сообществе. Запускаем, получаем цифры, сравниваем — готово. Но практика показала совсем другое.

Наша цель: оценить производительность с реальным профилем нагрузки от бизнес-системы на платформе 1С. 

Сроки: неделя на исследование.

Проблема традиционного подхода

Тест производительности Гилева — это своеобразный «дедушка» среди бенчмарков для 1С. Разработанный более 15 лет назад, он представляет собой относительно простой синтетический тест, показывающий способность платформы 1С выполнить определенное количество операций в единицу времени.

Плюсы теста Гилева:

• Простота запуска — буквально 15 минут на подготовку и запуск

• Стандартизация — все в сообществе знают, что такое «попугаи Гилева»

• Скорость получения результата — тест выполняется за 5-20 минут

• Минимальные требования к инфраструктуре — достаточно одного сервера

Минусы, критичные для облака:

1. Устаревшие алгоритмы

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

2. Синтетический характер нагрузки

Реальные пользователи 1С работают совсем не так, как имитирует тест Гилева. В реальности нагрузка распределена между несколькими серверами (сервер приложений, СУБД, веб-сервер), пользователи работают параллельно, создавая конкурентный доступ к ресурсам.

3. Отсутствие многопользовательского режима

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

4. Неадекватность для оценки сетевой подсистемы

В облаке критична производительность сети между компонентами. Тест Гилева эту составляющую практически не затрагивает.

5. Отсутствие проверки отказоустойчивости

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

Когда цифры не отражают реальность

Наш практический опыт показал, что результаты теста Гилева могут кардинально не соответствовать реальной производительности. 

Для примера: мы запустили этот тест у себя на проде и… получили 0,44 балла ?

Несколько слов о проде:

• СУБД (физический выделенный сервер): 128 CPU Intel Xeon Platinum 8358 2.6 GHz, 1500 GB RAM, NVMe

• Приложение (виртуальная машина на OpenStack): 64 CPU Intel Xeon Platinum 8358 2.6 GHz, 256 GB RAM, NVMe

На таком железе у нас работает один из самых высоконагруженных проектов на 1С: вся розница в режиме онлайн в единой базе (14 ТБ), ~7000 пользователей онлайн.

Тут совершенно очевидно: нужен принципиально другой подход к тестированию.

Тестовые стенды

В нашем распоряжении было 3 стенда в разных ЦОДах Beeline Cloud. 

Важная деталь: в качестве платформы виртуализации в двух ЦОДах используется VMware Cloud Director, в одном — OpenStack. Это позволило нам дополнительно оценить влияние платформы виртуализации на производительность 1С.

Конфигурация каждого тестового стенда была идентичной:

• Сервер приложений 1С: 20 vCPU / 64 GB RAM

• Сервер СУБД: 12 vCPU / 128 GB RAM

Отдельного внимания заслуживает дисковая подсистема. В каждом ЦОДе были доступны три типа дисковых пулов с разными характеристиками производительности:

• SSD — 5 IOPS/GB

• fSSD — 10 IOPS/GB

• uNVME — 25 IOPS/GB 

Принципы построения тестовой архитектуры

При проектировании стендов мы руководствовались несколькими ключевыми принципами:

1. Максимальное приближение к production-среде

Стенды были построены по классической трехзвенной архитектуре:

• Кластер серверов приложений 1С

• Выделенный сервер СУБД (MS SQL Server 2019)

2. Изоляция компонентов

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

3. Идентичность конфигураций

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

Предлагаемый подход: стандартный нагрузочный тест 1С ERP на 100 пользователей

Методология APDEX: от абстракции к реальным потребностям пользователей

Для объективной оценки производительности каждого стенда мы решили использовать рекомендуемую вендором методику APDEX (Application Performance Index). В качестве инструмента — готовый нагрузочный тест для ERP, который использует и сама компания 1С.

APDEX — это индустриальный стандарт измерения производительности приложений с точки зрения пользователя. В отличие от технических метрик (CPU, RAM, IOPS), APDEX отвечает на главный вопрос: «Довольны ли пользователи скоростью работы системы?» 

Принципы методологии APDEX

Методология классифицирует пользовательский опыт по трем категориям:

• Satisfied (Удовлетворены) — время отклика меньше ил�� равно пороговому значению T

• Tolerating (Терпимо) — время отклика от T до 4T

• Frustrated (Фрустрированы) — время отклика больше 4T

Итоговый индекс APDEX рассчитывается по формуле:

APDEX = (Satisfied + Tolerating/2) / Total Samples

Значение APDEX варьируется от 0 до 1, где:

• 1.00 — 0.94 = Отлично

• 0.93 — 0.85 = Хорошо

• 0.84 — 0.70 = Удовлетворительно

• 0.69 — 0.49 = Плохо

• Менее 0.49 = Неприемлемо

Пороговые значения для операций 1С

Компания 1С установила следующие пороги (T) для разных типов операций:

Быстрые операции (T = 2 сек):

• Открытие справочников

• Переход между формами

• Простые запросы без группировок

Стандартные операции (T = 5 сек):

• Создание и запись документов

• Проведение типовых операций

• Формирование простых отчетов

Сложные операции (T = 15 сек):

• Массовые операции с документами

• Сложные аналитические отчеты

• Операции пересчета остатков

Административные операции (T = 30 сек):

• Регламентные операции

• Обработка больших массивов данных

• Служебные процедуры

Конфигурация нагрузочного теста ERP

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

Структура теста на 100 виртуальных пользователей:

Финансы и взаиморасчеты (22 пользователя):

• Взаиморасчеты документы (16 человек) — обработка счетов, сверки

• Взаиморасчеты сервис (6 человек) — массовые операции

• Бухгалтер (3 человека) — проведение документов

Закупки (21 пользователь):

• Менеджеры по закупкам — анализ потребностей, работа с поставщиками

Склад и логистика (21 пользователь):

• Кладовщики документы (18 человек) — приемка, отгрузка

• Кладовщики сервис (3 человека) — массовые операции

Продажи и отгрузка (21 пользователь):

• Менеджеры по продажам (18 человек) — работа с клиентами

• Отгрузка сервис (3 человека) — планирование отгрузок

Производство (9 пользователей):

• Главный диспетчер (3) — общее планирование

• Локальный диспетчер (3) — оперативное управление

• Обеспечение потребностей (3) — планирование материалов

Интенсивность нагрузки:

• Высокая: операции каждые 1-3 минуты

• Средняя: каждые 5-10 минут

• Пиковая: массовые операции 1-2 раза в час

Реалистичность нагрузки

Ключевое отличие от теста Гилева — реалистичность паттернов использования:

1. Неравномерность нагрузки: пики активности в определенные часы (начало дня, запуск регулярных фоновых)

2. Различные профили пользователей: от «тяжелых» пользователей (аналитики) до «легких» (руководители)

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

4. Реальные объемы данных: работа с актуальными массивами информации, а не синтетическими наборами

Подготовка инфраструктуры к нагрузочным тестам

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

• СУБД MS SQL Server 2019 настроили под специфику 1С с учетом рекомендаций вендора и нашего опыта эксплуатации высоконагруженных систем.

• Для эмуляции 100 виртуальных пользователей использовали два терминальных сервера (64 vCPU/256GB RAM каждый). Можно было обойтись меньшими ресурсами, но у нас уже было шесть таких серверов для тестирования основной системы на 5500 пользователей — решили не изобретать велосипед.

• Автоматизация свелась к написанию PowerShell-скриптов для управления агентами Тест-Центра: по 5 агентов на каждом сервере, каждый из которых запускал по 10 виртуальных пользователей. Плюс скрипты для перезапуска кластера и очистки логов перед каждым новым прогоном — без этого результаты тестов получались несопоставимыми.

Подготовка данных и сценариев ERP

Выбор базового сценария тестирования

Для нагрузочного тестирования мы использовали готовый типовой сценарий «Полный» из поставки ERP + Тест-Центр. Этот сценарий включает все основные бизнес-процессы: от закупок и производства до продаж и финансового учета.

Проблема объема тестовых данных

Однако есть существенная проблема: типовая база от вендора содержит минимальный объем данных — буквально несколько сотен документов и записей в справочниках. На такой  «игрушечной» базе невозможно получить реалистичную картину производительности.

Для оценки реальной нагрузки нужен объем 1-2 лет работы предприятия. По нашим оценкам — примерно 1 ТБ данных. Именно при таком объеме начинают проявляться реальные узкие места системы: медленные запросы, проблемы с индексацией, обработка наборов данных на стороне сервера 1С.

Генерация реалистичного массива данных

Это оказался самый затратный по времени этап всей подготовки к тестированию. Простое копирование существующих записей не подходило — нужны были реалистичные связи между документами, корректные остатки, непротиворечивые данные по всем подсистемам ERP.

Структура сгенерированных данных:

• Справочники: 50 000 номенклатурных позиций, 5 000 контрагентов, 500 договоров

• Документы: около 2 млн документов всех типов за 24 месяца

• Остатки и обороты: реалистичные остатки на 20 складах с полной историей движений

• Регистры накопления: данные по себестоимости, взаиморасчетам, планированию

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

На полноценной базе в 1 ТБ картина производительности кардинально изменилась. Операции, которые на пустой базе выполнялись мгновенно, теперь требовали секунды или даже минуты. Зато это была уже реалистичная нагрузка — именно такую испытывают production-системы с историей в несколько лет работы.

На полноценной базе в 1 ТБ картина производительности кардинально изменилась. Операции, которые на пустой базе выполнялись мгновенно, теперь требовали секунды или даже минуты. Зато это была уже реалистичная нагрузка — именно такую испытывают production-системы с историей в несколько лет работы.

Особенно заметна разница: 

• Аналитические отчеты (время выросло в 10-50 раз)

• Пересчет себестоимости (критична дисковая подсистема)

• Работа с большими документами (влияние сетевых задержек)

• Конкурентный доступ к популярным справочникам

Именно на таком объеме данных стали видны реальные различия между ЦОДами, которые совершенно не проявлялись в тесте Гилева или на небольших базах.

Методика проведения тестов

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

Почему 3 повторения:

• Исключение случайных всплесков производительности

• Выявление деградации производительности во времени

• Получение статистически значимых результатов для расчета APDEX

• Возможность отбраковать результаты с аномальными значениями

 Для исключения внешних факторов все тесты проводились:

• В одинаковое время (с 09:00 до 18:00) для минимизации влияния соседних ВМ

• В будние дни для обеспечения стабильной сетевой нагрузки ЦОД

• После предварительной проверки отсутствия запланированных работ в ЦОДах

Результат теста считался валидным только при соблюдении всех условий:

• Успешное завершение работы всех 100 виртуальных пользователей

• Отсутствие критических ошибок в логах 1С и SQL Server

• Разброс результатов между повторениями не более 15%

• Стабильное использование ресурсов без пиковых нагрузок.

Такая методология позволила получить максимально объективные и сравнимые результаты по всем трем ЦОДам.

Сравнительный анализ: тест Гилева vs нагрузка ERP в разных ЦОДах/облаках

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

Парадокс production-среды

Самый яркий пример несостоятельности теста Гилева — результаты production-системы. При максимальном индексе APDEX (0.884), что означает отличный пользовательский опыт, тест Гилева показал катастрофически низкий результат (0.44). Это объясняется тем, что production-система оптимизирована под реальную нагрузку, но все эти оптимизации не влияют на синтетические операции теста Гилева.

Обратная корреляция результатов

В нескольких случаях наблюдается также интересная ситуация — стенды с лучшими показателями Гилева демонстрируют худшие значения APDEX. Например, DC1 с uNVME показал 31.45 «попугаев» Гилева, но APDEX всего 0.848, в то время как стенд Vega с результатом Гилева 7.86 обеспечил APDEX 0.861.

Причины расхождений

 1. Различие в характере нагрузки

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

2. Влияние объема данных

На «тонких» тестовых базах, которые использует тест Гилева, не проявляются проблемы с производительностью запросов к большим объемам данных. Наши ERP-тесты на базе в 1 ТБ выявляют реальные узкие места в производительности инфраструктуры.

3. Специфика облачной виртуализации

В облачной среде производительность зависит от множества факторов, невидимых для теста Гилева: тип гипервизора, соседние ВМ, особенности СХД. ERP-тесты длительностью несколько часов с реалистичной нагрузкой выявляют эти особенности.

Плюсы и минусы методики

Преимущества методологии APDEX для облачных решений

1. Ориентация на пользовательский опыт

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

2. Учет специфики 1С

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

3. Сравнимость результатов

APDEX позволяет объективно сравнивать различные инфраструктурные решения.

4. Прогнозируемость

Результаты тестов хорошо коррелируют с производительностью в production-среде.

Практические сложности реализации

Несмотря на очевидные преимущества, внедрение полноценного нагрузочного тестирования сталкивается с рядом вызовов:

Временные затраты:

• Подготовка тестовой базы: 2-3 дня

• Настройка сценариев: 1-2 дня 

• Проведение тестов: 3-5 дней

• Анализ результатов: 1 день

Ресурсные требования:

• Необходимость развертывания полноценной инфраструктуры

• Требования к квалификации специалистов

• Лицензионные затраты на тестовые базы

Техническая сложность:

• Настройка многопользовательских сценариев

• Обеспечение стабильности длительных тестов

• Интерпретация большого объема метрик

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

Заключение

Опыт пилотной оценки площадок Beeline Cloud показал очевидное: для осознанного выбора облака под 1С ERP недостаточно полагаться на синтетические тесты. Ключевой тезис этой работы прост и практичен — выбирать ЦОД и профиль инфраструктуры нужно на основе нагрузочных испытаний реальных сценариев ERP, а не по «абстрактным баллам» синтетического бенчмарка. Именно такой подход выявляет реальные узкие места и показывает, как система поведет себя в типовых операциях пользователей и регламентных процедурах.

Предложенная методика — развертывание типового трехзвенного стенда 1С ERP, подготовка данных и сценариев на 100 одновременных пользователей, единые профили ВМ и хранилищ — дала практический результат за неделю. Мы получили воспроизводимую процедуру сравнения ЦОДов и профилей ресурсов, где каждый замер сопо��тавим, а «стоимость за производительность» стала прозрачной. Такой формат снимает большую часть рисков внедрения: позволяет заранее оценить соответствие SLA, избежать деградаций при пиковых нагрузках и аргументированно выбирать конфигурации.

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

---

P.S. Напоминаем про вебинар 18 ноября — расскажем больше практических кейсов по 1С и поделимся чек-листом по критическим настройкам 1С. [Регистрируйтесь]

P.P.S. А как вы тестируете производительность 1С? Доверяете синтетическим тестам или используете что-то другое? Давайте обсудим в комментариях.