Не всё так просто в нагрузочном тестировании ☝
Мы провели 500+ нагрузочных тестов, пробили 150 000 запросов в секунду (RPS) и получили стабильные результаты. Казалось, система готова к эксплуатации. Но в продуктивной среде картина сложнее. Полина Корнеева, руководитель направления в отделе разработки интеграционных решений, развеивает 5 иллюзий из опыта:
➡️ «Система выдержала 150 000 RPS — значит, готова к бою» Высокая цифра показывает потенциал платформы, но на реальном трафике могут возникнуть сложности.
➡️ «Синтетика = реальность» Синтетический тест упрощает реальность, для объективной оценки нужны более разнообразные сценарии.
➡️ «Все запросы одинаковы» На поведение системы влияют тип вызова, размер запроса и ответа, частота обращений, поведение клиентов и реакция бэкэнд-систем.
➡️ «Если ошибок <0,001%, всё в порядке» Статистически допустимый фон на тестах может стать вполне ощутимым в рабочей среде.
➡️ «Синтетика бесполезна» Синтетические тесты — неотъемлемая часть подхода, который комбинирует их с реальными сервисами и анализом наблюдений.
Читайте в статье подробнее о том, какой опыт мы из этого извлекли.
· 28.04
Узнаю боль — у нас та же история была с Node.js сервисом. 150k RPS в синтетике, потом первый же продовый spike положил всё за 30 секунд.
Самый коварный пункт — "все запросы одинаковы". В реальности всё ломается на edge cases: пользователь с 10 годами истории, запрос который попадает в cold cache, коллбэк который приходит через 2 секунды а не 200ms.
Мы в итоге перешли на shadow traffic — записываем реальные запросы и воспроизводим на стейдже с коэффициентом x10. Только так стали находить баги которые синтетика не ловит.
Какой у вас подход к воспроизведению реального трафика в тестах?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён