Стенд для нагрузочного тестирования на Testcontainers (материалы для статьи).md
Статья: Стенд для нагрузочного тестирования на Testcontainers
Материалы
https://habr.com/ru/companies/ozontech/articles/777570/
Если вы хотите оптимизировать код, поведение которого пока не наблюдаемо, вам необходимо сперва навесить на него метрики.
https://habr.com/ru/companies/ozontech/articles/662800/
Нагрузочное тестирование (load testing) оценивает поведение компонента или системы в условиях увеличивающейся нагрузки, например при увеличении количества параллельных пользователей и/или количества транзакций, чтобы понять, выдержит ли этот компонент или система подобную нагрузку. Упор делается на ожидаемую и реалистичную нагрузку, хотя в основу этого НТ включают разнообразные сочетания запросов и их количество. Запросы создаются таким образом, чтобы смоделировать одновременную работу набора пользователей. Это позволяет оценить время ответа и пропускную способность. Иногда разделяют многопользовательское НТ с разумным/реалистичным количеством пользователей и объёмное НТ с огромным количеством пользователей.
https://github.com/yandex/yandex-tank
Обзор инструментария для нагрузочного и перформанс-тестирования - https://habr.com/ru/companies/jugru/articles/337928/
Дальнейшие шаги, развитие
Тут можно описать проблемы
Будущие направления и возможности расширения.
Благодаря тому, что у нас параметры статически через alias мы можем часть конфигурации куда-то вынести.
А что если нужен сложный сценарий для wiremock? Возможно сделать кастомный сервис на java c wiremock внутри и с чуть большим количеством мозгов. Это уже stub?
Settings for JFR
Using options like dumponexit=true,disk=true with -XX:StartFlightRecording:settings= should ideally force JFR to
write metrics. However, in some cases, this doesn’t work as expected. To ensure proper recording, it’s necessary to
manipulate timings. Please ensure that tests run for a duration longer than the duration=120s setting.
Так как этот стенд построен на testcontainers, мы можем тестировать сервисы на java, go и т.д. Цепочки сервисов и т.д. и все в комфортном формате spock тестов с возможностью прогона тестов по набору версий или настроек: where: image | threadsVirtualEnabled ‘rdc-local:1.13.2’ | false ‘rdc-local:1.14.0’ | false ‘rdc-local:1.14.0’ | true
Нагрузка описывал через gatling или wrk, можно другие варианты посмотреть. Для отчета возможет сбор GC логов, хипдампов, JFR и т.д. Вот пример пакета отчетов из readme, что в MR
Вырезки
А что если нет докер образа? [todo]
Определение окружения: Конфигурирование контейнеров с помощью Testcontainers.
базы данных, кеши, очереди и т.д.
https://overload.yandex.net/login/?next=/mainpage/guide#install https://overload.yandex.net/online/705659#tab=test_data&tags=&plot_groups=main&machines=&metrics=&compress_ratio=1
Spock и Testcontainers
Я долго время использую Spock для написание тестов и для меня он представляет удобную
В целом наверное очевидно, что использование Testcontainers позволяет нам описать окружение в виде баз данных, кешей, брокеров очередей и мок-сервисов довольно просто и удобно. Но почему не docker-compose? Первую версию стенда я на нем и сделал. Но столкнулся с неудобством по контролю за жизненным циклом контейнеров и необходимостью параметризировать запуск сценариев. Дополнительно хотелось бы чтобы среда для работы с тестами для программиста была однородной. Если у нас основной инструмент это Gradle + Spock Framework + Testcontainers и можно сделать стенд для нагрузочного тестирования именно на этих инструментах, то давайте и сделаем.
Изоляция и воспроизводимость тестов. Простота интеграции с CI/CD. Возможность тестирования различных конфигураций и версий ПО.
Позволяет программно конфигурировать контейнеры, изменяя их параметры в зависимости от потребностей конкретного теста.