Comments 6
Нагрузочное тестирование делается на тестовом окружении? Если да, то оно должно быть максимально идентично продакшену, чтобы быть уверенным, что там тоже всё будет хорошо.
Да, нагрузочное тестирование должно проводиться на тестовом окружении, максимально приближенном к продакшену. Без этого результаты бесполезны и создают ложную уверенность.
Критически важно совпадение:
- Конфигураций (Веб-сервер, БД, JVM)
- Типов и характеристик железа/облачных инстансов (особенно Disk I/O и сеть)
- Версий всего ПО и оркестрации
- Сетевых задержек до внешних сервисов
Идеал — полная копия. Если дорого — scaled-down копия с теми же типами ресурсов, но в меньшем количестве. Это позволяет находить архитектурные проблемы (утечки памяти, блокировки БД) и сравнивать производительность версий.
Главное правило: отличие в инфраструктуре делает цифры (RPS, latency) нерелевантными для прода, но может помочь выявить системные баги.
Ох уж этот стиль изложения ChatGPT... Как же я устал от этого...
Вот бы раскрыть тему, "А КАК?" собственно тестировать. Ну вот сделали мы новую ручку/функционал/джобу, на неё НТ тесты же не написаны, а только на старое, и в итоге все равно надо лезть в k6 и править.
А бывает что внешние сервисы вызываются, это же ещё и моки постоянно держать, что бы не валить ничего
Согласен с автором. Нагрузочное тестирование, особенно в больших проектах, сэкономит литры кофе, образно говоря ☕️
В нашем open-source проекте мы тоже используем k6, только не блочим мердж (а надо бы :)). Мы еще отправляем метрики в графану - так можно увидеть динамику. Сама джоба, если интересно, на гитхабе.
Как мы вшили нагрузочное тестирование в CI/CD, чтобы не хоронить фичи в проде глубокой ночью