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

Пик приходит не тогда, когда вы ждёте

В обычный день у магазина десять заказов в час, и всё работает. В день акции рассылка уходит в 10:00, и в первые пятнадцать минут на сайт заходит больше людей, чем за прошлую неделю. Форма оформления отвечает по полминуты, платёж зависает, бот молчит. Люди закрывают вкладку и уходят к соседнему магазину.

Нагрузочный тест нужен, чтобы увидеть этот сценарий за месяц до события, а не в 10:05 в день акции. Про сам инструмент и пошаговую настройку я уже писал в статье про JMeter. Здесь о другом: что именно считать, что проверять и что делать, если запас кончился.

Как оценить пик до теста

Берёте три источника: статистику прошлого года из метрики, план рекламы и график рассылок. Нужны пиковый час прошлой Чёрной пятницы и самые тяжёлые пятнадцать минут внутри него.

Условный пример. Допущения такие: в прошлом году в пиковый час было 3000 посетителей и 60 заказов (конверсия 2%). В этом году вы планируете рекламу и ждёте вдвое больше людей, то есть 6000 в час. Рассылка собирает 40% часового трафика в первые 15 минут: это 2400 человек, или 160 в минуту. Посетитель сидит на сайте в среднем четыре минуты.

Число одновременных посетителей считают так: приход в минуту умножить на время на сайте. 160 на 4 это около 640 человек одновременно. Заказов за те же 15 минут будет около 48, примерно три в минуту. Для теста закладывают запас в полтора раза, то есть около 1000 одновременных посетителей. Числа взяты для примера, свои подставьте из метрики.

Три заказа в минуту выглядят безобидно. Нагружают сайт 640 человек, которые одновременно листают каталог, считают доставку и оформляют корзины.

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

Форма оформления. Подсказки адресов, проверка промокода, расчёт доставки: каждый такой вызов это отдельный запрос к вашей базе или чужому сервису. Под нагрузкой он замедляется первым.

Платёжный шлюз. Лимиты на количество запросов у провайдера свои, они написаны в договоре или документации. Спросите у провайдера напрямую, я их не называю. Боевой шлюз нагружать нельзя: тест идёт на тестовом режиме или на заглушке.

База данных. Когда сто человек одновременно покупают один товар, база списывает остаток по очереди, и запросы начинают ждать друг друга.

Интеграция с 1С и складом. Обмен часто идёт по расписанию. В пик остатки на сайте отстают от склада, и вы продаёте товар, которого уже нет. Проверьте, как часто обновляются остатки и что происходит при сбое обмена.

SMS и письма. У провайдера есть очередь и свои ограничения по скорости. Код подтверждения, который пришёл через три минуты, это потерянный заказ.

Бот в мессенджере. Здесь ограничения на стороне площадки. По документации Telegram Bot API: в одном чате не больше одного сообщения в секунду, в группе не больше 20 сообщений в минуту, при массовой рассылке около 30 сообщений в секунду, при превышении приходят ошибки 429. В документации MAX указано: не больше двух сообщений в секунду в один диалог, группу или канал, превышение советуют обходить очередью или задержкой. Простая арифметика: рассылка на 10 000 человек при 30 сообщениях в секунду займёт больше пяти минут. Планируйте её заранее.

Что спросить у исполнителя

«Протестировали, всё нормально» это не отчёт. Попросите в письменном виде пять вещей.

Первое: на какой нагрузке шёл тест, в одновременных пользователях и заказах в минуту. Второе: время ответа по ключевым страницам, главной, каталогу, корзине, оформлению. Смотреть нужно 95-й процентиль: среднее прячет тех, кто ждал в десять раз дольше. Третье: доля ошибок, то есть запросы с кодами 5xx, таймауты, обрывы. Четвёртое: на каком шаге нагрузки время ответа резко выросло. Пятое: что исполнитель предлагает исправить и в каком порядке.

Порог провала лучше согласовать заранее, до теста. Условный пример: оформление заказа отвечает быстрее трёх секунд на 95-м процентиле, ошибок меньше одного процента. Конкретные числа выбирайте под свой бизнес.

Тест на копии сайта на другом железе даёт приблизительную картину. Помните об этом при чтении отчёта.

План на случай превышения

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

Очередь заказов. Заказ принимается и сохраняется сразу, а тяжёлые шаги (запись в 1С, SMS, уведомления) выполняются следом, по очереди. Покупатель сразу видит подтверждение.

Режим предзаказа. Если остатки не успевают обновляться, переводите товар в предзаказ: сайт принимает заявку и не обещает наличие.

Упрощённая форма. Телефон, имя, способ получения. Без подсказок адресов и лишних проверок. Остальное уточнит менеджер или бот.

Статичная страница «мы получили заказ». Лёгкая страница без обращений к базе, которую сайт отдаёт, пока основной контур перегружен. Статус потом можно показывать по ссылке из сообщения, чтобы клиент не писал вам с вопросом «где мой заказ».

Мониторинг в день акции

О падении вы должны узнавать раньше покупателя. Настройте мониторинг сайта и домена с уведомлением в мессенджер и добавьте проверку самой корзины вместе с главной страницей. Остальные недели подготовки разобраны в чек-листе на 8 недель. Перед нагрузкой обязательно пройдите обычную проверку бота и сайта: тест производительности бессмысленен, если корзина ломается уже у одного человека.

Нагружать можно только свой сайт и согласовав окно с хостинг-провайдером. Чужие платёжные страницы и API не трогают.

Что делаю я

Я провожу нагрузочный тест до сезона: считаем пик по вашей статистике, прогоняем сценарий покупателя со ступенчатой нагрузкой и отдаю отчёт по пунктам выше. Дальше настраиваю запасные режимы: очередь заказов, предзаказ, упрощённую форму, статичную страницу. Подробности на странице DevOps и поддержка сайтов.

Частые вопросы

За сколько до акции делать тест?

Лучше за три-четыре недели. Если найдётся узкое место, на его исправление и повторную проверку нужно время.

Если трафик небольшой, тест всё равно нужен?

Да, если планируется реклама или рассылка. Один рекламный пост может привести за час больше людей, чем сайт видел за месяц.

Можно ли проверить только бота?

Можно, но лимиты платформы тестом не поднять. Проверяют вашу часть: очередь сообщений и поведение бота при ошибках 429.

Коротко о главном

Пик считают заранее: прошлогодний час, план рекламы и время на сайте дают число одновременных посетителей. Первыми ломаются форма оформления, платёжный шлюз, база, обмен с 1С, SMS и рассылки в боте. У исполнителя просят нагрузку, время ответа на 95-м процентиле, долю ошибок и порог провала, а на случай превышения готовят очередь, предзаказ и упрощённую форму.

Хотите узнать, сколько заказов выдержит ваш сайт и бот до 27 ноября? Напишите мне в Telegram кодовое слово «ПИК» и дату вашей ближайшей акции. Посчитаю пик по вашим цифрам и скажу, что проверить в первую очередь.