Как провести стресс-тест сайта самостоятельно и понять, когда он упадет?

Представьте классический кошмар владельца бизнеса: вы выделили 5 миллионов рублей на масштабную рекламную кампанию у топовых блогеров. Трафик льется рекой, заявки должны бить рекорды. Но вместо потока клиентов вы получаете шквал гневных сообщений, а на месте вашего интернет-магазина красуется белая страница с надписью «503 Service Unavailable» или «502 Bad Gateway». Бюджет сгорел, репутация испорчена, клиенты ушли к конкурентам.

Чтобы этого не допустить, нужно заранее знать предел прочности вашего ресурса. В этой статье инженеры NineLab подробно расскажут, что такое нагрузочное тестирование, почему сайты вообще «падают» и как провести базовый стресс-тест своими руками.

Что такое стресс-тест и чем он отличается от нагрузочного тестирования?

Многие путают эти два понятия:

• Нагрузочное тестирование (Load Testing): мы проверяем, как сайт справляется с ожидаемым количеством пользователей. Например, мы знаем, что в Черную Пятницу придет 5 000 человек в час, и смотрим, не будет ли тормозов.
• Стресс-тестирование (Stress Testing): мы намеренно «заливаем» сайт трафиком до тех пор, пока он не сломается. Наша задача — найти ту самую точку отказа (bottleneck) и посмотреть, как именно система «умирает» (и, что важнее, как быстро она восстанавливается после).

Важное правило: никогда не проводите стресс-тест на рабочей (production) базе в часы пик. В идеале для тестов должна быть развернута точная копия вашего сайта (staging-окружение).

Почему вообще падают сайты? 3 узких горлышка архитектуры

Бизнесу часто кажется, что сайт падает, потому что «не хватает сервера» или «мало оперативной памяти». На практике в 90% случаев проблема кроется глубже:

1. База данных не справляется с очередью (Locks): Десять пользователей одновременно пытаются сформировать корзину. База данных начинает блокировать записи, чтобы избежать конфликтов. Одиннадцатый пользователь ждет своей очереди и отваливается по таймауту.
2. Лимит подключений к веб-серверу: Ваш Nginx или Apache настроен на одновременную обработку 500 соединений (максимум воркеров). 501-й пользователь просто не сможет подключиться и получит ошибку 502 или 504.
3. Отсутствие кэширования: Когда 10 000 человек заходят на главную страницу, сервер вынужден каждый раз заново генерировать ее с нуля, запрашивая меню, каталог и цены из базы данных. Это загружает процессор до 100% за считанные секунды.

Инструменты для самостоятельного тестирования

Если вы хотите получить лишь общее представление о надежности, не обязательно быть DevOps-инженером (о том, какие метрики мониторинга использовать, мы писали ранее). Существуют простые утилиты и облачные сервисы для генерации синтетической нагрузки.

1. k6 Cloud / Grafana k6

Один из самых современных инструментов от Grafana Labs. Базовый сценарий пишется на JavaScript. Сервис удобен тем, что имеет облачную версию (позволяет эмулировать реальный разброс пользователей по всему миру) и выдает красивые, понятные графики времени отклика и отказов.

2. Apache Benchmark (ab)

Классическая консольная утилита, которая поставляется вместе с веб-сервером Apache. Идеальна для быстрых и грубых проверок. Программа настолько популярна, что на MacOS или Linux (Ubuntu) она уже установлена по умолчанию.

ab -n 1000 -c 100 https://vash-sayt.ru/

Где -n 1000 — это общее количество запросов, а -c 100 — количество одновременных подключений.

В отчете нас прежде всего интересуют параметры:

• Failed requests: если здесь не 0, значит, ваш сервер уже не переварил даже эту небольшую нагрузку.
• Requests per second (RPS): сколько реальных запросов в секунду способен отдавать ваш сервер.

3. Yandex.Tank (Яндекс.Танк)

Более серьезная "артиллерия" от Яндекса. Это мощный инструмент для высоконагруженных систем, который умеет агрегировать отчеты по перцентилям. Однако для его тонкой настройки уже понадобится базовая техническая экспертиза.

3 фатальные ошибки при самостоятельном тестировании

Если вы решили обойтись своими силами, остерегайтесь ловушек, которые сделают результаты вашей проверки бесполезными:

1. Тестирование статичных страниц. Тестировать главную страницу или старую статью в блоге бессмысленно — скорее всего их мгновенно отдаст система кэширования (или CDN). Проверять нужно самые «тяжелые» и динамические маршруты: внутренний поиск по каталогу, добавление товаров в корзину или оформление заказа.
2. Стрельба из одной точки. Если вы запустите скрипт со своего ноутбука через офисный Wi-Fi, вы протестируете пропускную способность своего роутера, а не сервера. Правильные тесты запускаются с распределенных мощных серверов.
3. Игнорирование сценариев (User Flow). Реальный покупатель не заходит на сайт 10 000 раз в секунду. Он открывает каталог, кликает параметры, кладет товар "в корзину". Хороший стресс-тест всегда имитирует реалистичные шаги пользователя.

Анализ результатов: что делать дальше?

Вы запустили нагрузку и увидели ошибку. Сайт упал. Что делать?

Самостоятельный тест ответит на вопрос «упадем ли мы?». Но он никогда не ответит на вопросы «ПОЧЕМУ мы упали?» и «КАК это исправить?».

Если система сложилась под трафиком, это далеко не всегда означает, что вам нужно срочно покупать железо за полмиллиона рублей в месяц. Возможно, вам нужно просто поднять Redis для кэширования агрегации фильтров. Или переписать один медленный SQL-запрос, который блокирует остальные таблицы. А при серьезных амбициях — переработать архитектуру-монолит, внедрив микросервисы и балансировщики нагрузки (как в нашем кейсе по высоконагруженной реферальной системе).

NineLab специализируется на проектировании отказоустойчивых (high-load) инфраструктур. Мы не ограничиваемся простой отправкой ботов на сайт. Мы проводим глубокий технический аудит узких мест, выстраиваем геораспределенную инфраструктуру и оптимизируем узлы так, чтобы ваш ресурс выдержал даже самые вирусные рекламные кампании. Не рискуйте бизнесом перед важным релизом — доверьте стабильность бренда инженерам.