Тест Гилева – нагрузочный тест, с помощью которого можно сделать выводы о быстродействии платформы «1С:Предприятие». Многие ИТ-специалисты уделяют много внимания итогам данного теста. Причём в большей степени однопоточному тесту, так как считают его более наглядным и простым. Однако это не до конца верно.
Однако тест Гилева на деле не показывает быстродействие настоящей конфигурации с настоящей базой данных. Обычно его запускают на пустой платформе, так как изначально его придумали для проверки дискретных серверов. Однако тест можно запустить на настоящей рабочей системе.
В статье расскажем о том, как влияют те или иные варианты оптимизации виртуальной машины, гостевой ОС и различное ПО на показатели теста Гилева.
Начальные данные
Тест Гилева обычно применяется для того, чтобы сделать выводы о производительности при хранении баз данных 1С с использованием СУБД, но подойдёт и для файлового варианта хранения. Он идёт в формате файла конфигурации (*.cf), который можно загрузить в конфигураторе «1С:Предприятие».
Тест можно разделить на две части. Каждую из них можно запускать отдельно.
Часть 1 – однопоточный тест, который позволяет оценить производительность операций в один поток. Это характерная черта платформы «1С:Предприятие». По итогам теста выстраивается график в форме столбчатой диаграммы. Читать его следует слева направо. На графике показаны результаты настоящего теста, а также результаты, которые соответствуют условным оценкам «плохо» (10), «удовлетворительно» (15), «хорошо» (35) и «отлично» (60).
Часть 2 – многопоточный тест, который позволит оценить скорость, с которой осуществляется запись на диски при параллельном отправлении запросов к базе данных. Выходной результат представляет собой наибольшие скорости одного потока, наибольшую скорость записи и количества юзеров, рекомендованное для одновременной работы. Вторая часть теста недоступна, если используется файловая архитектура хранения баз.
Результаты можно также сохранить в облако, где их можно сравнить с результатами тестов, сделанных другими пользователями.
Среда тестирования
Чтобы провести тест в «стандартном» облаке Cloud4Y мы развернули ВМ с гостевой операционкой Windows Server 2019 из базового шаблона с паравиртуальным драйвером дисков.
В роли СУБД выступил Microsoft SQL Server 2019 версии Standard. Версия Express приведёт к аналогичным результатам тестирования, но её нельзя применять на реальных базах, так как в ней есть ограничения.
На ВМ инсталлировали сервер «1С:Предприятие» и выполнили настройку кластера серверов 1С. Инсталлировали добавочные средства администрирования серверов 1С. Конфигурация была только одна – сам тест Гилева.
Чтобы протестировать раздельную конфигурацию, при которой сервер 1С и СУБД помещены на различные ВМ, мы выполнили клонирование начальной виртуальной машины, а потом в гостевой операционной системе каждой из ВМ удалили ненужные компоненты и выполнили дополнительную настройку.
Сделанные оптимизации
- Для ВМ. На машинах, где проходит тестирование, убрали опции добавления виртуальных процессоров и RAM в процессе работы, так как это потенциально снижает производительность.
- Для гостевой операционной системы. Здесь использовались рекомендации с https://its.1c.ru, https://gilev.ru и некоторых других ресурсов. Рекомендации проверялись на актуальность, как выяснилось, часть из них была написана для устаревших версий ОС. Были выполнены следующие действия:
- отключены опции энергосбережения в гостевой операционке и установили режим наибольшей производительности
- отключены на уровне системы протокол IPv6, сделан ключ DisabledComponents, имеющий тип DWORD (32 б) и обозначенным в реестре, как 0xffffffff. Он располагается здесь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters. Это означает отключение всех компонентов IP версии 6, исключая интерфейс замыкания на самого себя. Вместо протокола IPv6 в политиках префиксов окажется версия 4.
- Для СУБД. Были произведены следующие манипуляции:
- Выполнена установка минимально требуемого комплекта компонентов СУБД MSSQL
- Выставлено ограничение на использование памяти сервером СУБД: минимум – половина объёма RAM, максимум – полный размер оперативки, минус 1 ГБ на каждые выделенные 16 ГБ
- Настроена максимальная степень параллелизма, равная 1
- Разнесены по разным файловым системам на отдельных виртуальных дисках базы tempdb, базы данных пользователей и логи
- Тонко настроены параметры баз model и tempdb: стартовый объём базы от 1 ГБ до 10 ГБ, журнала транзакций – от 1 ГБ до 2 ГБ и авторасширение – 512 МБ
- В СУБД добавлено разрешение на операции по обслуживанию томов
- В варианте раздельной архитектуры установлена политика «Блокировка страниц в памяти» для юзера, от кого запускался сервер СУБД. В совместной архитектуре подобная политика не применяется
- Для общей архитектуры убрали все протоколы обмена данными, исключая shared memory, а для раздельной архитектуры – всё, кроме tcp
Запуск теста
Теперь можно оценить, какое влияние оказывают разные настройки инфраструктуры
Виртуальные процессоры и сокеты
Изображения 1-3 показывают, как сильно влияют сокеты в случае совмещённой конфигурации. Наибольшие значения получаются, когда сокет всего один. Чем их больше, тем результаты теста ниже.
Изображения 4 и 5 показывают, как влияет увеличение числа виртуальных процессоров. Особого подъёма результатов от увеличения количества процессоров не наблюдается.
Примечание: однако важно учитывать, что в работе с настоящей базой данных, а также при подключении более одного юзера увеличение числа виртуальных процессоров ощутимо повлияет на производительность.
Объём RAM
Следующим шагом разберём влияние RAM
Тест показывает, что увеличение объёма памяти не даёт заметного прироста.
Примечание: нужно учесть, что с настоящей базой данных и в случае, когда подключается более, чем один юзер, объём RAM ощутимо скажется на производительности.
Объём кластера файловой системы тома с базой данных
На изображениях 7-9 видно, какое оказывает влияние на производительность размер кластера файловой системы тома, где расположена база данных. Это влияние настолько мало, что им можно пренебречь.
Примечание: Для настоящей базы данных размер кластера файловой системы заметно влияет на производительность. Так что стоит брать размер кластера, который рекомендуется для соответствующего размера тома.
Совместная или раздельная архитектура
Изображение 10 отражает итоги тестирования для раздельной архитектуры (то есть используется отдельный сервер СУБД). Конфигурация СУБД в этом случае в расчёт не берётся, важна лишь конфигурация сервера, в рамках которого развёрнута платформа «1С:Предприятие». По итогам теста видно, что производительность у раздельной архитектуры ощутимо ниже, чем в случае совместной. Это обосновано тем, что применяется протокол tcp вместо shared memory, который является более быстрым.
Нагруженность кластера и выделение ресурсов
Изображение 11 демонстрирует результаты теста на ВМ, которая находится на хосте, изолированном от основного кластера. Результаты ощутимо выше предыдущих, так как все ресурсы хоста гарантированно идут на нужды единственной ВМ.
Изображение 12 демонстрирует итоговые значения теста в общем кластере, где активны политики гарантированного выделения ресурсов. Показатели ощутимо ниже, чем на изолированном хосте.
Выводы
- На итоговые показатели теста сильнее всего влияет исключение любых настроек энергосбережения в гостевой ОС и исходная частота виртуального процессора
- Нагруженность кластера, где работает ВМ, может значительно влиять на итоги теста
- Совмещённая архитектура показывает лучшие результаты, чем раздельная благодаря применению протокола shared memory, который является более быстрым. Но при такой архитектуре придётся следить за ресурсами, которые используют отдельные компоненты системы, чтобы не допустить конкуренции
- Ощутимая часть советов с https://its.1c.ru и https://gilev.ru, не подходит для современных версий ОС и СУБД
Напоминаем, что не стоит принимать решения только на основе синтетических тестов. Cloud4Y проводил тест Гилева по 1С в виртуальной среде на не очень мощных процессорах. Возможно в будущем появится тест на новом «железе».
