Нагрузочное тестирование: как подготовить систему к росту

Зачем вообще нагрузочное тестирование

Большинство сбоев в продакшене случаются не из-за ошибок в коде, а из-за того, что система внезапно получила больше запросов, чем рассчитывали. Маркетплейс запускает акцию, банк рассылает push о новой возможности, госуслуга появляется в новостях — и за несколько минут трафик вырастает в десятки раз. То, что работало месяцами на спокойной нагрузке, начинает отдавать таймауты, копить очереди и в худшем случае полностью ложится.

Нагрузочное тестирование — это управляемая репетиция такого всплеска. Вы заранее, в безопасной обстановке, узнаёте: сколько одновременных пользователей выдержит система, где у неё потолок, что именно сломается первым и как она ведёт себя в момент отказа. Это разница между «мы знаем свой предел и подготовились» и «мы узнали свой предел во время самой важной акции года».

Какие метрики действительно важны

Главная ошибка — смотреть только на «выдержала или нет». Нагрузочное тестирование даёт набор метрик, и каждая рассказывает свою часть истории. Игнорировать любую из них — значит получить ложное чувство уверенности.

• Время отклика (latency) — и обязательно в перцентилях, а не среднее. Среднее в 200 мс может скрывать, что 5% пользователей ждут по 4 секунды. Смотрите p50, p95 и p99 — именно «хвосты» формируют впечатление о медленном сервисе.
• Пропускная способность (throughput, RPS) — сколько запросов в секунду система обрабатывает без деградации. Это ваш реальный потолок мощности.
• Частота ошибок (error rate) — доля ответов 5xx, таймаутов, оборванных соединений. Рост ошибок под нагрузкой важнее, чем абсолютное число.
• Утилизация ресурсов — CPU, память, диск, сеть, число открытых соединений к базе. Без этих цифр вы не поймёте, что именно стало бутылочным горлышком.
• Поведение при насыщении — что происходит, когда нагрузка превышает потолок: система плавно деградирует или резко обваливается.

Виды тестов и сценарии

«Нагрузочное тестирование» — это зонтичный термин. На практике под разные цели применяют разные виды тестов, и важно не путать их.

Сценарии должны повторять реальное поведение пользователей, а не дёргать один эндпоинт. Реальный пользователь логинится, листает каталог, кладёт товар в корзину, оформляет заказ, оплачивает. Каждый из этих шагов нагружает разные части системы по-разному. Тест, который бьёт только в главную страницу, покажет красивые цифры и ничего не скажет о том, выдержит ли оформление заказа. Закладывайте паузы между действиями (think time), разное соотношение операций чтения и записи, и обязательно — реальную работу с базой данных, а не закэшированные ответы.

Где обычно прячутся узкие места

По нашему опыту, узкое место почти никогда не там, где его ждут. Чаще всего проблема не в «медленном коде», а в инфраструктуре и работе с данными.

• База данных — самый частый виновник. Отсутствующие индексы, запросы N+1, блокировки при конкурентной записи, исчерпание пула соединений. Под нагрузкой база упирается в потолок раньше всего.
• Пулы соединений и потоков — приложение само по себе живо, но количество одновременных соединений к базе или внешнему API ограничено, и запросы выстраиваются в очередь.
• Внешние интеграции — платёжные шлюзы, SMS-провайдеры, сторонние API. Их лимиты и таймауты становятся вашими лимитами. Под нагрузкой медленный внешний сервис подвешивает ваши потоки.
• Отсутствие или неправильное кэширование — каждый запрос пересчитывает то, что можно было закэшировать на секунды.
• Один сервер без горизонтального масштабирования — частая реалия проектов в Узбекистане, где старт делают на одном VPS. До определённого момента это нормально, но потолок наступает быстро, и о нём нужно знать заранее.

Подготовка к запуску или акции

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

Тестируйте на окружении, максимально близком к продакшену по конфигурации и объёму данных. Тест на ноутбуке разработчика не значит ничего. Запускайте нагрузку из нескольких источников, чтобы не упереться в ограничения самого инструмента. И главное — после того как нашли и устранили узкое место, повторяйте тест: исправление одного бутылочного горлышка часто просто перемещает его на следующий уровень.

Отдельно подготовьте план на случай отказа: настройте мониторинг и алерты заранее, определите, кто дежурит в момент запуска, продумайте механизмы graceful degradation — отключение тяжёлых необязательных функций под пиком, очереди вместо синхронной обработки, заглушки вместо падения. Система, которая под перегрузкой отдаёт чуть урезанный функционал, в разы лучше той, что показывает белый экран.