Привет, Хабр!
Сегодня расскажем, как мы совместно с DigiLabs разработали методику нагрузочного тестирования облачных провайдеров и провели его среди наиболее популярных российских компаний, которые предоставляют облачную платформу для 1C.
Навигация по тексту:
→ Как мы считали индекс производительности
С чего все началось
Началось все с того, что наша команда разработки Рег.ру в сотрудничестве с DigiLabs разработала платформу для 1С, с учетом специфики и требований приложения. И тогда нам потребовалось доказать в первую очередь себе (а затем — нашим клиентам), что инфраструктура действительно подходит для размещения 1С. Команда Дарьи Величаевой (DigiLabs) подготовила методологию тестирования с полной имитацией интенсивных действий пользователей.
Спойлер: тест показал, что наша платформа не менее чем на 30 % производительнее, чем другие, доступные сейчас облака. С некоторыми провайдерами разница составляла до 90 %.
Существует всем известный и широко используемый нагрузочный тест, но он имеет недостаток: однопоточность. Поэтому он показывает не совсем релевантные результаты. Еще один недостаток имеющихся тестов, по нашему мнению, — минимальный объем данных в тестовых базах, так как с проблемами производительности чаще сталкиваются обладатели баз весомых объемов. Не найдя готового способа объективного сравнения производительности инфраструктуры, мы решили разработать свой тест, позволяющий точнее оценить производительность многопользовательских баз.
Итак, задача была такова: проверить, насколько хорошо держит высокую нагрузку от 1С собранная нами платформа.
Что мы сделали
Взяли одну из самых ресурсоемких конфигураций — «1С:ERP Управление предприятием». Наполнили ее достаточным объемом данных (150 Гб, также потом проводили тест на базе 500 Гб). Используя подсистему «Тест-центр», входящую в состав «1С:Корпоративный инструментальный пакет», разработали многопользовательский сценарий, эмулирующий работу пользователей. Каждый виртуальный пользователь в рамках многопользовательского теста выполняет последовательность операций, имитирующих процесс продаж. Тест ограничен по времени (15 минут), количество выполненных операций зависит от производительности стенда.
Разрабатывая методику тестирования, мы старались сделать комплексную оценку производительности, поэтому помимо скорости выполнения операций учитывали степень загруженности оборудования сервера 1С и сервера СУБД. В ходе теста анализируются следующие показатели:
количество выполненных ключевых операций;
среднее, максимальное и минимальное время выполнения ключевых операций;
оценка интегральной производительности APDEX;
утилизация процессора сервера 1С и сервера СУБД;
очередь к дискам сервера 1С и сервера СУБД;
задержка дисков сервера 1С и сервера СУБД;
потребление памяти сервера 1С и сервера СУБД.
Таким образом, даже получив схожие значения оценки производительности разных стендов с точки зрения выполнения операций, мы можем увидеть, где железо перегружено, а где простаивает.
Для сбора метрик ОС используем службу telegraf, после окончания теста подгружаем метрики в 1С.
Для проведения нагрузочных тестов мы выбрали следующие конфигурации серверов:
сервер СУБД: ОС Windows, 48 vCPU, 128 ГБ оперативной памяти;
сервер 1С: ОС Windows, 32 vCPU, 64 ГБ оперативной памяти;
версия платформы 1С: 8.3.23.1912;
версия MSSQL:Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) Enterprise Evaluation (64-bit);
VMware ESXi: 8.0.2, 22380479.
Для воспроизведения нагрузки использовались 100 ВРМ (виртуальных рабочих мест). Тут стоит оговориться, что данное число не отражает количество реальных пользователей, которые могут работать в данной конфигурации серверов. ВРМ создают более интенсивную нагрузку. Целью теста является сравнение различных стендов при одинаковых ресурсах и одинаковой нагрузке.
Кроме многопользовательского сценария подготовили еще один: с «болью» многих — регламентной операцией закрытия месяца. Она длительная и сложная, но очень важная для пользователей.
Как мы считали индекс производительности
В процессе проведения тестов и обсуждения результатов, пришли к тому, что бизнес просит более простых и понятных метрик. Поэтому оставили такие понятия как общая интегральная оценка, квантили метрик ОС и APDEX для детального анализа, а в качестве наиболее наглядных и понятных результатов использовали количество выполненных за отведенное время операций, среднее время выполнения ключевых операций, а также не забывали сравнивать стоимость инфраструктуры, поэтому ввели такую метрику как количество операций на 1000 рублей.
Мы сравнили среднее время выполнения основных ключевых операций многопользовательского сценария:
Немаловажным фактором при выборе облачного провайдера является стоимость, поэтому мы сравнили стоимость тестируемых конфигураций:
При проведении второго теста, включающего закрытие периода, динамика производительности сохранилась, мы получили похожие цифры прироста производительности нашей инфраструктуры по сравнению с другими.
Один из наших клиентов проводил свое нагрузочное тестирование разных платформ с использованием других методологий, в том числе HammerDB. И их тест подтвердил наши показатели производительности.
Что в итоге
Сейчас вся группа Рунити перенесла часть своих баз данных на инфраструктуру, разработанную и протестированную совместно с DigiLabs (а это главный показатель нашего доверия к своему продукту). Платформа устраивает нас и как внутреннего заказчика, и как поставщика услуг: этот же продукт используют и наши клиенты.
