Стресс-тест сайта: зачем он нужен и как его проводят

Вопрос, на который отвечает тест, звучит просто: что произойдёт, если завтра придёт в двадцать раз больше людей, чем обычно. Ответ «наверное, справимся» стоит дорого — рекламная кампания, сюжет в СМИ или чёрная пятница выясняют это за вас и без подготовки.

Виды тестов: нагрузочный, стресс, стабильности, спайк

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

Что измеряют

• Время ответа — сколько сервер отдаёт страницу под нагрузкой. Смотреть надо не среднее, а верхние проценты: среднее скрывает то, что каждый десятый посетитель ждал десять секунд.
• Пропускную способность — сколько запросов в секунду обрабатывается без ошибок.
• Долю ошибок — процент ответов 5xx и обрывов соединения. Разбор кодов — ошибки 5xx.
• Ресурсы сервера — процессор, память, диск, соединения к базе. Именно здесь обычно и находится узкое место.
• Время восстановления — за сколько сайт возвращается в норму после снятия нагрузки. Сайт, который лёг и не встал сам, — отдельная категория проблемы.

RPS — число запросов, которое сервер обрабатывает за секунду. Цель теста формулируют в RPS, а не в «пользователях онлайн»: один посетитель делает запрос раз в минуту, другой — десять раз в секунду. Порог времени ответа задают заранее по перцентилю, например p95 до 800 мс для страниц каталога; долю ошибок обычно допускают не больше 1%, для оплаты — ноль.

Как это делают

1. Определяют сценарии. Не «зайти на главную», а реальный путь: каталог → карточка → корзина → оформление. Тяжёлые страницы отличаются от лёгких в десятки раз.
2. Задают профиль нагрузки. Сколько виртуальных пользователей, как быстро они прибывают, сколько держится пик.
3. Тестируют на копии. Стресс-тест боевого сайта — это и есть авария, только организованная своими руками.
4. Наращивают нагрузку ступенями до появления ошибок, фиксируя показатели на каждой ступени.
5. Ищут узкое место. Обычно это база данных, реже — процессор или ограничения тарифа хостинга.
6. Чинят и повторяют. Тест без второго прогона после правок ничего не доказывает.

Инструменты для этого есть и бесплатные, и облачные — с генерацией нагрузки из разных регионов. Выбор инструмента вторичен: результат определяется реалистичностью сценариев, а не названием программы.

Как посчитать целевую нагрузку по данным Метрики

Цифра «пусть выдержит 10 000 пользователей» обычно взята с потолка. Профиль строят по статистике самого загруженного периода и плану маркетинга на пик. Пример:

1. Пиковый час. В прошлую распродажу было 60 000 визитов в день, из них в пиковый час — 6 000 (10% суточных).
2. Просмотры. В среднем 6 страниц за визит — 36 000 просмотров в час, или 10 в секунду.
3. Запросы к приложению. Статику отдаёт nginx или CDN. На просмотр приходится HTML-страница плюс 2–3 AJAX-запроса (фильтр, корзина, подсказки поиска), около 4. Итого 40 RPS.
4. Рост на событие. Маркетинг ждёт в 5 раз больше трафика — 200 RPS.
5. Запас. Умножаем на 1,5 на ошибку прогноза: цель теста — 300 RPS при p95 до 800 мс и ошибках меньше 1%.

Число одновременных посетителей считают по закону Литтла: L = λ · W, где λ — визиты в секунду, W — длительность визита. 6 000 визитов в час — это около 1,67 в секунду; при визите 5 минут на сайте одновременно около 500 человек, в распродажу — около 2 500. Эти цифры нужны, чтобы проверить сессии и лимиты соединений.

Сценарии тоже берут из Метрики: 3–5 путей, которые дают основную нагрузку и выручку, с долями — например, 60% каталог и карточки, 25% поиск и фильтр, 10% корзина, 5% оформление заказа.

Если стенда нет и тест идёт на боевом сайте

• Ночное окно и заранее назначенный человек, который останавливает тест.
• Оплата в тестовом режиме, SMS, письма и выгрузка заказов в 1С или CRM — на заглушках, иначе тест создаст тысячи фиктивных заказов.
• Хостинг предупреждён — иначе он примет тест за атаку.
• IP генераторов нагрузки в белом списке защиты от DDoS, иначе вы протестируете фильтр с капчей и ошибкой 429.
• Те же IP исключены в фильтрах Метрики, чтобы не испортить статистику и автостратегии Директа.
• Свежая резервная копия и человек, который смотрит на мониторинг.

Когда тест обязателен

• Перед крупной рекламной кампанией. Трафик приходит резко, и падение сайта означает, что бюджет откручивается в пустоту.
• Перед распродажей и сезонным пиком. Чёрная пятница — классический сценарий отказа.
• После редизайна или переезда на новый сервер: конфигурация другая, старые выводы не действуют.
• При выходе на телевидение или в крупные СМИ — самый быстрый и предсказуемый способ положить сайт.
• Если сайт уже падал. Причину нужно найти воспроизведением, а не догадками.

Что делать с результатами

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

Порядок действий обычно такой: кэширование → оптимизация запросов к базе → отдача статики через CDN → и только потом увеличение мощности. Первые три шага часто дают кратный запас без роста ежемесячных затрат. Смежная тема — скорость загрузки сайта: она про одного пользователя, стресс-тест — про тысячу одновременно.

Что обычно ломается первым

• База данных. Запрос без индекса на пустой базе занимает миллисекунды, на каталоге в 200 тысяч товаров — секунды, под нагрузкой — очередь и блокировки.
• Воркеры PHP-FPM. Когда все процессы заняты, запросы ждут, а nginx отдаёт 502 или 504. Поднимать лимит вслепую нельзя: каждому процессу нужна память.
• Кеш, который сбрасывается. Если выгрузка из 1С обнуляет кеш раз в 10 минут, он почти не помогает.
• Файловые сессии. Блокируются на время запроса, и параллельные AJAX-запросы посетителя встают в очередь. Помогает перенос сессий в Redis.
• Внешние API. Пока расчёт доставки отвечает две секунды, запрос держит PHP-процесс, и воркеры заканчиваются. Нужны таймауты, кеш и асинхронные вызовы.

В Битриксе композитный режим отдаёт главную из кеша, и её тест ничего не скажет о корзине, поиске и личном кабинете — в сценариях нужны некешируемые действия и авторизованные пользователи. Агенты, которые выполняются на хитах посетителей, переводят на cron. В WordPress и WooCommerce корзина и авторизованные пользователи идут мимо страничного кеша, нагрузку дают admin-ajax.php и wp-cron. Тестируйте дважды: с прогретым кешем и сразу после его сброса — второй прогон покажет, что будет после выгрузки из 1С в разгар распродажи.

Исправления делятся на настройки сервера, доработку кода и масштабирование: серверную часть закрывает настройка сервера, кодовую — доработка сайта.

Чек-лист подготовки

• Определено событие и дата: распродажа, кампания, запуск или переезд
• По Метрике посчитана целевая нагрузка с запасом, заданы пороги p95, p99 и доли ошибок
• Выбраны 3–5 сценариев с долями, включая корзину, поиск и авторизацию
• Есть стенд с конфигурацией и данными как на боевом сайте или согласовано ночное окно
• Оплата, SMS, письма и выгрузка заказов переключены на заглушки
• Хостинг предупреждён, IP генераторов в белом списке и исключены из Метрики
• Настроен мониторинг сервера и базы, есть резервная копия и ответственный за остановку
• Запланированы исправления и повторный прогон до события

Коротко

• Нагрузочный тест проверяет плановый пик, стресс-тест ищет точку отказа, тест стабильности — утечки за часы, спайк-тест — резкий всплеск.
• Цель задают в RPS по данным Метрики с запасом, а не в «пользователях онлайн».
• Измеряют время ответа, пропускную способность, долю ошибок, ресурсы сервера и восстановление.
• Смотреть надо верхние проценты времени ответа, а не среднее.
• Тестируют на копии и по реальным сценариям, а не по одной главной странице.
• Узкое место чаще в базе данных и отсутствии кэширования, чем в мощности сервера.
• Обязателен перед крупной рекламой, распродажей, после редизайна и переезда.