Нагрузочное тестирование сайта перед чёрной пятницей: проверяем сервер и базу данных

Чёрная пятница и сезонные распродажи дают интернет-магазинам пик трафика в 5–10 раз выше обычного — и именно в эти часы каждая минута простоя стоит дороже всего. По данным Google, 53% мобильных пользователей уходят с сайта, если страница грузится дольше трёх секунд, а во время распродажи покупатель просто перейдёт к конкуренту. Нагрузочное тестирование — способ заранее узнать, где сломается сайт: на сервере, в базе данных или в интеграции с 1С. В этой статье разбираем, как рассчитать целевую нагрузку, написать сценарии на k6 и Locust и найти узкие места до того, как их найдут покупатели.

Что измеряем: метрики, которые решают всё

Нагрузочное тестирование отвечает на один вопрос: при каком потоке пользователей система начинает деградировать. Отвечаем через четыре ключевые метрики. Пропускная способность (RPS) — сколько запросов в секунду выдерживает система без потери качества. Время ответа смотрят не по среднему, а по перцентилям: p95 и p99 показывают, сколько ждут самые медленные 5% и 1% запросов — именно они формируют очередь на «касс». Доля ошибок: в норме — меньше 0,1–1% (таймауты, ответы 5xx). Наконец, ресурсы инфраструктуры: если процессор уходит за 80% или заканчиваются соединения с базой данных — предел найден.

Как рассчитать целевую нагрузку

Возьмите статистику пиков прошлого года из Яндекс.Метрики и логов сервера, затем заложите рост. Формула: RPS = (посетители в час пика × страниц за визит) / 3600 × коэффициент запросов. Пример: ожидаете 50 000 посетителей за 6 часов акции, каждый открывает 12 страниц — получаем около 28 обращений к страницам в секунду. Но каждая страница тянет за собой API-запросы, статику и корзину, поэтому умножаем на 4 — выходит примерно 110 RPS. Добавьте запас ×1,5–2 на всплески от рассылок и таргетированной рекламы: целевая нагрузка — 170–220 RPS. Отдельно посчитайте локальные пики: массовое добавление в корзину в первые минуты акции создаёт нагрузку в 3–5 раз выше средней.

k6 и Locust: что выбрать под вашу команду

Оба инструмента бесплатны и с открытым кодом, но заточены под разные задачи. k6 (от Grafana Labs) написан на Go, сценарии описываются на JavaScript, один инстанс генерирует тысячи виртуальных пользователей, а встроенные thresholds автоматически «роняют» тест, если p95 превысил лимит — это удобно для CI/CD. Locust — Python-фреймворк с веб-интерфейсом в реальном времени и распределённым режимом из коробки: десятки воркеров объединяются в единый поток нагрузки. Практическое правило: нужна максимальная нагрузка с одного стенда и автопроверки в пайплайне — берите k6; сценарии сложные (авторизация, многошаговая корзина, случайное поведение) и в команде есть Python-разработчики — Locust.

Тестируем весь путь покупателя, а не только главную

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

• каталог с фильтрами и сортировкой — тяжёлые запросы к базе данных;
• поиск — самый ресурсоёмкий механизм в большинстве магазинов;
• карточка товара и вывод остатков на складе;
• добавление в корзину и пересчёт — активная запись в БД и сессии;
• оформление заказа и платёжный шлюз (только через тестовый контур!);
• интеграции: синхронизация остатков с 1С, отправка заказов в CRM, SMS-уведомления;
• API мобильного приложения, если оно есть.

Интеграции заслуживают отдельного внимания: при пике заказы пишутся в 10 раз чаще, и очередь в 1С становится узким местом быстрее, чем сам сайт.

Пять ошибок, которые обнуляют результаты теста

Даже правильно написанный сценарий бесполезен, если нарушена методика. Проверьте, что не совершаете этих ошибок:

• Стенд слабее продакшена. Результаты с VPS за 1 500 ₽ ничего не скажут о боевом сервере — стенд должен повторять конфигурацию по версиям ПО и объёму данных.
• Нагрузка без мониторинга. RPS и время ответа без APM и дашбордов (Grafana, Prometheus) не покажут, почему система тормозит.
• Тест без предупреждения хостинга. Анти-DDoS-фильтры примут атаку на прод за реальную и заблокируют ваш IP.
• Один короткий прогон. Только ступенчатое наращивание нагрузки находит точку деградации.
• Тёплый кэш и чужие лимиты. Тест на прогретом кэше при холодном проде даст ложный оптимизм, а rate limits платёжных шлюзов и SMS-провайдеров испортят оформление заказов.

Пошаговый план подготовки к пиковым дням

Если свести всё в регламент, подготовка к распродаже выглядит так:

1. Соберите пиковую статистику прошлого года: Метрика, логи nginx, данные мониторинга.
2. Рассчитайте целевой RPS с запасом ×1,5–2.
3. Опишите сценарии по воронке покупателя, включая интеграции с 1С и CRM.
4. Подготовьте стенд, идентичный продакшену, или согласуйте ночной тест в бою.
5. Разверните мониторинг: Prometheus + Grafana, APM, медленные запросы БД.
6. Проведите ступенчатый тест и зафиксируйте точку, где p95 выходит за лимит.
7. Устраните узкие места: индексы БД, кэширование, вынос статики на CDN, масштабирование, очереди для интеграций.
8. Повторите тест и зафиксируйте результат как точку отсчёта на следующий сезон.

Нагрузочное тестирование перед распродажей — страховка, которая стоит на порядок дешевле самого простоя. Если в час пик магазин делает 500 000 ₽ и сайт упал на два часа, потери — миллион рублей плюс репутация и слитая в минус реклама. Аудит и тестовый прогон на k6 или Locust занимают у опытной команды несколько дней и почти всегда находят узкое место — чаще всего им оказывается не сервер, а база данных или интеграция с 1С. Мы проводим нагрузочное тестирование в рамках подготовки магазинов к распродажам: рассчитаем целевую нагрузку по вашей статистике, напишем реалистичные сценарии и подготовим инфраструктуру к пиковым дням. Свяжитесь с нами — проведём тест раньше, чем это сделает чёрная пятница.