Привет, Хабр! Меня зовут Максим Шишкин, я инженер по нагрузочному тестированию в команде Platform V Works::Artifactory в СберТехе. Наше решение — менеджер репозиториев артефактов и контейнеров. Он позволяет организовать хранение, описание, тегирование сборок и дистрибутивов программных продуктов, а также готовых Docker-контейнеров.

В этой статье я расскажу, как и почему мы перешли на Java 17, как протестировали возможности нового сборщика мусора Z Garbage Collector и в результате сэкономили ресурсы виртуальных машин — а вместе с этим и финансы. Надеюсь, наш опыт будет полезен инженерам по сопровождению, командам разработки и тестирования.

Любая команда рано или поздно сталкивается с вопросом: как рационально использовать ресурсы стендов? В процессе развития команды получают несколько стендов для своих задач. Чаще всего проблем с утилизацией стендов ПСИ (приёмо-сдаточные испытания), ИФТ (интеграционно-функциональное тестирование), ДЕВ (разработка) не возникает. Но есть исключение — стенд НТ (нагрузочное тестирование).

Безусловно, стенд НТ должен быть максимально приближен к ПРОМу (промышленный стенд): это база. Но все прекрасно понимают, что при заказе больших ресурсов нужно будет и использовать их должным образом. А если использование недостаточное, может, лучше урезать ресурсы и сэкономить средства компании или перераспределить их?

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

В процессе нагрузочного тестирования мы решили улучшить наш продукт Platform V Works::Artifactory в рамках технического спринта. Желание понятное и вполне реализуемое.

В первую очередь решили перейти на более свежую версию Java, в нашем случае — с Java 11 на Java 17. Особенно нас заинтересовал новый Z Garbage Collector (ZGC) — масштабируемый сборщик мусора с низкой задержкой. В разных статьях приводились интересные числа по эффективности ZGC, но неизменным было одно: он значительно улучшал производительность тестируемых продуктов.

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

После перехода на Java 17 мы решили провести замеры и зафиксировать, так сказать, полученную прибыль. Но всё оказалось не так однозначно.

Мы сравнили с предыдущим сборщиком G1 GC (Garbage first Garbage Collector), который зарекомендовал себя самым лучшим образом. Для чистоты эксперимента замеряли на одной версии продукта Platform V Works::Artifactory 2.7.0, на одном стенде. Ресурсы во время тестирования никак не менялись, профиль нагрузки не изменялся и состоял из 38 операций. Результаты утилизации ресурсов представлены на рисунках ниже. КТС (комплекс технических средств) стенда НТ соответствует нашему сайзингу для 500 пользователей и приведён ниже.

Таблица 1. КТС стенда НТ:

На первый взгляд, ничего не поменялось, кроме использования памяти. При использовании Java 17 c ZGC резервируется около 4 Гб ОЗУ (RAM), а всё остальное практически целиком используется под кеш. В результате мы решили уменьшить ОЗУ на сервере Artifactory в два раза, до 16 Гб, и проверить работоспособность продукта при таком значении. Но об этом чуть ниже, а пока зафиксируем показатели по всем операциям и сравним их между собой.

Таблица 2. Результаты тестов надёжности по каждой операции:

Результаты получились впечатляющие. Улучшение времени отклика зафиксировано практически по всем операциям. 95 % и 99 % — это, соответственно, 95-й и 99-й перцентили времени отклика, выраженные в миллисекундах (мс).  

К важным операциям можно отнести операции с репозиториями (с 1 по 6) и поиск (7 операция). В нашем случае все они получили хороший прирост. Где‑то прирост составил 51 % (операции c репозиторием Maven), а где‑то — целых 86 % (операции c репозиторием RAW).

Показатели нескольких операций (а именно четырёх) не улучшились, а даже наоборот. К примеру, худший результат — это увеличение времени отклика в два раза (или на 103 %, 38 операция). Увеличение с 40 мс до 81 мс, в целом, для нас не критично, как и с 37 операцией. А вот 13 и 34 операции мы взяли на доработку. После этого нас заинтересовало изменение в утилизации памяти, и вот об этом поподробнее.

Мы и раньше исследовали продукт на разных КТС, увеличивали и уменьшали значения ЦПУ (CPU) и ОЗУ. Но в конечном счёте пришли к тому, что самая работоспособная версия, которая соответствует всем требованиям и критериям, — это именно версия на 16 ядер ЦПУ и 32 Гб ОЗУ.

И вот тут для нас Java 17 c ZGC заиграла новыми красками. КТС стенда НТ изменился, уменьшилось ОЗУ до 16 Гб только на сервере Artifactory.

Таблица 3. КТС стенда НТ:

В результате проведённого на этих ресурсах НТ с использованием Java 17 c ZGC удалось подтвердить работоспособность и надёжность конфигурации. Этот КТС стал новым сайзингом для 500 пользователей. Данные по утилизации ресурсов во время тестов приведены ниже.

Рисунки и результаты конкретного продукта — это, конечно, хорошо. Но их необходимо сравнить не только между собой, но и с конкурентами на рынке. В качестве конкурента выступит Sonatype Nexus Repository.

Для сравнения с результатами нашего продукта я взял две конфигурации (Medium и Large) из документации Nexus Repository. С точки зрения ресурсов Platform V Works::Artifactory с сайзингом для 500 пользователей, который мы и тестируем на стенде НТ, находится практически между ними.

Sonatype Nexus Repository Architecture 2 (Medium Profile Size) состоит из одного сервера (Node) c двумя ядрами CPU и 8 Гб RAM. Architecture 3 (Large Profile Size) состоит из трёх серверов. Суммарно для такой архитектуры нужно 12 ядер CPU и 48 Гб RAM. Напомню, что для нашей версии нужно 16 CPU и 16 RAM.

Получается, что Artifactory необходимо чуть больше СPU, но при этом кратно меньше RAM. В документации продукта Sonatype Nexus Repository используются такие понятия, как RPH (количество запросов в час) и RPD (количество запросов в день). На основе этих данных рекомендуются соответствующие архитектуры (конфигурации). Профиля нагрузки в документации нет, есть только показатель за час (фактически тест подтверждения максимальной производительности) и за день (фактически тест надёжности).

Спомощью несложных математических расчётов вычисляем, что, исходя из документации Sonatype Nexus Repository, день длится 10 часов. Или же, если погрузиться в основы методики нагрузочного тестирования (МНТ), тест надёжности должен составлять около 70-80% интенсивности нагрузки теста подтверждения максимальной производительности. Таким образом, если взять величину 80 %, то получается, что день длится 12,5 часов.

Мы проводим тесты надёжности длительностью сутки или более. Конечно же, бывают исключения, тем не менее, надёжность подтверждается на нагрузке в 24 часа. Но для простоты подсчёта и сравнения тоже возьмём 10 часов.

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

Таблица 4. Сравнение с Sonatype Nexus Repository:

Даже если стоимость эксплуатации была бы одинаковой (4 ядра CPU у Artifactory по стоимости эксплуатации были бы равны 32 Гб RAM у Sonatype Nexus Repository Architecture 3 (Large)), можно сказать, что использование Java 17 и ZGC позволило нашему продукту показать более высокую эффективность и производительность. В данном случае разница в сопоставлении с Sonatype составляет 26 %.

Заключение

Пора подводить итоги, они зафиксированы в таблице ниже. С одной стороны, ZGC и Java 17 приятно удивили своей производительностью в целом и утилизацией ОЗУ в частности. Но неожиданно удивило и потребление ЦПУ. В нашем случае потребление выросло на 20 %. Это не самый приятный момент, особенно в условиях ограниченности ресурсов.

Хотя, если посмотреть на ситуацию иначе, на стенд НТ было выделено 16 ядер CPU, и это значение осталось неизменным. А значит, стоимость эксплуатации в этом компоненте для нас не изменилась, в отличие от RAM. По результатам данного исследования, RAM уменьшилась в два раза (на 16 Гб) без негативного эффекта — и это хороший результат и экономия, заложенная в будущую эксплуатацию продукта.

Надеемся, что наши эксперименты и результаты будут полезны и для вас. Спасибо за внимание!