Как подготовить сайт к резкому росту трафика и не потерять продажи

Рекламная рассылка, публикация у блогера, сезонная распродажа или запуск нового продукта могут привести на сайт сотни посетителей за несколько минут. Кампания выглядит успешной, но страницы начинают открываться по 10–15 секунд, поиск зависает, корзина не обновляется, а часть пользователей получает ошибки 502, 503 или 504. Бизнес продолжает оплачивать переходы, хотя сайт уже не способен нормально принимать заказы.

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

Почему сайт перестаёт отвечать не от трафика, а от одновременной нагрузки

Серверу опасно не само количество посещений за сутки, а плотность запросов в коротком промежутке времени. Десять тысяч переходов, равномерно распределённых на день, и тысяча переходов за пять минут создают совершенно разную нагрузку. Во втором случае десятки или сотни пользователей одновременно открывают страницы, запускают PHP, обращаются к MySQL, выполняют поиск и добавляют товары в корзину.

Средняя суточная посещаемость поэтому почти бесполезна для оценки готовности к рекламному пику. Нужны как минимум запросы в секунду, число активных сессий, Time to First Byte, среднее время ответа и 95-й процентиль. Последний показывает границу, быстрее которой обслуживаются 95% запросов, и лучше отражает деградацию, чем среднее значение, сглаживающее редкие, но болезненные задержки.

Сопоставьте аналитику по минутам с access.log Nginx или Apache. Найдите самый плотный интервал, посчитайте количество запросов и посмотрите, когда начали расти 5xx и время ответа. Сайт обычно падает не от цифры в отчёте за сутки, а от слишком плотного пика.

Какие компоненты заканчиваются первыми при наплыве посетителей

Узкое место ищут по симптомам, а не угадывают по тарифу. Главная страница может ещё открываться, пока каталог, фильтры или оформление заказа уже стоят в очереди. Бывает и обратная картина: CPU загружен наполовину, но пользователи ждут свободный PHP-процесс, подключение к базе или ответ внешней CRM.

PHP-процессы и очередь запросов

Когда все PHP-FPM workers заняты, новые динамические запросы ждут освобождения обработчика. CSS и изображения при этом могут загружаться быстро, а HTML, поиск и корзина — зависать. В такой ситуации первым делом смотрят не канал связи, а PHP-FPM и базу данных.

Состояние пула проверяют через status-страницу PHP-FPM, если для неё заранее настроен pm.status_path и ограничен доступ. Дополнительные признаки ищут в журнале PHP-FPM, error.log веб-сервера и сообщениях о достижении pm.max_children или лимита процессов аккаунта.

База данных и медленные запросы

Поиск, фильтры, сортировка, корзина и персональные кабинеты часто создают больше нагрузки, чем обычный просмотр страницы. Каталог может работать быстро, пока пользователь не включит фильтр: один неудачный SQL-запрос в такой точке под нагрузкой размножается десятками копий. Для MySQL полезны slow query log, SHOW FULL PROCESSLIST, показатель Threads_connected и анализ блокировок.

Оперативная память, CPU и диск

Нехватка RAM приводит к активному использованию swap, после чего сервер начинает отвечать рывками. Высокий CPU чаще указывает на дорогую генерацию страниц, но сам по себе не объясняет причину. Команды top, free -m, vmstat и iostat помогают увидеть память, load average, iowait и процессы, создающие нагрузку. Процессор свободен — ещё не значит, что серверу легко.

Внешние сервисы, API и коды 502–504

Медленный ответ платёжного шлюза, CRM, службы доставки или стороннего API удерживает PHP-процесс и увеличивает очередь. Добавление ядер в таком случае почти не помогает. Нужны таймауты, логирование длительности внешних вызовов, безопасные правила повторных запросов и кеширование ответов, когда данные это допускают.

Коды 502 и 503 не указывают на одну универсальную причину. Ошибка 502 может появиться при недоступности upstream, аварийном завершении PHP-FPM или некорректном ответе приложения; 503 способен вернуть веб-сервер, приложение или инфраструктура при перегрузке. Ошибка 504 чаще означает, что прокси не дождался ответа PHP-FPM, приложения или внешнего сервиса в установленный таймаут.

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

Ожидаемую нагрузку считают по одновременным пользователям и динамическим запросам в секунду, а не по общему числу переходов. Маркетинговый прогноз переводят в технический сценарий: сколько людей придёт за минуту, сколько страниц откроет каждый, какие действия запустят PHP и MySQL, сколько продлится активная сессия.

Перевод маркетингового прогноза в технические показатели

Если ожидаются 3000 переходов за 10 минут, среднее значение составит 300 посетителей в минуту. Но это ещё не готовая модель. Один пользователь может открыть посадочную страницу, каталог и карточку товара, отправить несколько AJAX-запросов, добавить товар в корзину и перейти к оплате. Маркетинг считает переходы, а сервер — запросы.

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

Расчёт пикового, а не среднего сценария

Поток редко распределяется идеально ровно. Рассылка или публикация у блогера часто дают самый плотный наплыв в первые минуты. Поэтому готовят три сценария: ожидаемый, пиковый и пиковый с резервом. Запас в 30–50% допустим как стартовый ориентир, но не как универсальная норма: тяжёлый поиск и простая кешированная страница расходуют ресурсы по-разному.

Запас на повторные запросы и фоновые процессы

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

Что можно ускорить без немедленной смены хостинга

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

Полностраничное и объектное кеширование

Full-page cache подходит для страниц, одинаковых для большинства посетителей: статей, категорий, карточек товара без персональных данных. Redis или Memcached сокращают повторные вычисления и обращения к базе на уровне объектов. После настройки проверяют hit ratio, число PHP-процессов и время ответа некешируемых URL. Ошибка в исключениях опаснее отсутствия кеша: пользователь может увидеть чужую корзину или устаревший статус заказа.

CDN, изображения и статические файлы

CDN снимает с основного сервера раздачу изображений, CSS, JavaScript и файлов, если кеш настроен корректно. Дополнительно помогают WebP или AVIF, реальные размеры изображений и lazy loading ниже первого экрана. Lighthouse и DevTools покажут тяжёлые ресурсы, но не заменят серверные замеры: быстрый первый экран ещё не доказывает, что MySQL выдержит одновременное оформление заказов.

Оптимизация базы и тяжёлых функций

Для WordPress и WooCommerce стоит проверить Query Monitor, slow query log, индексы таблиц, разросшиеся временные записи и плагины, выполняющие внешние запросы при каждом открытии страницы. Cron-задачи лучше запускать системным планировщиком, а не привязывать к посещениям. Перед кампанией перенесите резервное копирование, массовый импорт, пересчёт каталога и другие тяжёлые операции на спокойное время.

Рост трафика в десять раз не требует автоматического увеличения тарифа в десять раз. Если каталог отдаётся из кеша и статика уходит через CDN, нагрузка на PHP и базу растёт заметно медленнее посещаемости.

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

Когда текущего хостинга уже недостаточно

VPS нужен не из-за самого факта роста посещаемости, а когда сайт упирается в подтверждённые лимиты общей среды или требует недоступных настроек. Признаками могут быть постоянная очередь PHP-FPM, нехватка RAM, ограничение числа процессов, достижение max_connections MySQL, отсутствие Redis или невозможность изменить конфигурацию Nginx и PHP.

Обычного хостинга иногда хватает интернет-магазину с хорошо кешируемым каталогом. Небольшой проект с тяжёлым поиском, персонализацией и множеством внешних API, наоборот, может раньше потребовать изолированной среды. Считать нужно не посетителей, а стоимость обработки одного запроса.

При выборе инфраструктуры смотрят не только на диск и число ядер, но и на доступную RAM, лимиты процессов, возможность настроить кеш, доступ к логам, резервное копирование и скорость увеличения ресурсов. Посмотреть, какие варианты инфраструктуры доступны для таких сценариев, можно на сайте UkrLine, но конфигурацию лучше выбирать после замеров, а не по максимальным цифрам в описании тарифа.

После переноса или вертикального масштабирования повторите тот же тест. Если узкое место осталось, проблема могла находиться в коде, базе или внешнем сервисе. Новая инфраструктура без контрольного замера даёт лишь ощущение запаса.

Как провести нагрузочное тестирование и не положить рабочий сайт

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

Какие пользовательские сценарии тестировать

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

Как повышать нагрузку поэтапно

В k6, JMeter или Locust нагрузку лучше поднимать ступенями: сначала проверить ожидаемый поток, затем пик и только после стабильного прохождения добавить резерв. На каждом шаге фиксируют 95-й процентиль, долю ошибок, очередь PHP, подключения MySQL, CPU, RAM и iowait. wrk подходит для узких технических проверок, но не заменяет сложный пользовательский сценарий.

Когда тест нужно остановить

Остановите рост нагрузки, если быстро увеличивается доля 5xx, время ответа не восстанавливается после ступени, включается активный swap, MySQL приближается к лимиту соединений или нарушается работа корзины и авторизации. На боевом сайте нельзя искать предел методом «добавляем пользователей, пока не упадёт»: заранее задают критерии остановки и человека, который имеет право прекратить тест.

Интенсивную проверку безопаснее проводить на staging, максимально близком к рабочей среде. Тест production согласовывают с провайдером и выполняют только с заранее определёнными пределами.

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

Что контролировать во время рекламной кампании

Во время пика одновременно наблюдают за временем ответа, HTTP-ошибками, PHP-процессами, памятью, базой и ключевыми действиями пользователей. Код 200 ещё не означает, что магазин работает: страница может открыться, а AJAX-запрос корзины, создание заказа или callback платёжной системы уже возвращают ошибку.

Серверные метрики и базовая линия

До теста зафиксируйте базовую линию: обычный 95-й процентиль, число активных PHP-процессов, подключения MySQL и расход памяти при нормальном трафике. Тревожные значения удобнее определять относительно этой линии, а не по универсальным порогам. Минимальный набор для наблюдения — доля 5xx, RAM и swap, CPU, iowait, очередь PHP-FPM и подключения MySQL.

Бизнес-события

Технические графики дополняют количеством успешных заказов, оплат, регистраций и отправок форм. Если трафик растёт, а подтверждённые действия внезапно прекращаются, проверяйте фронтенд, JavaScript, API, корзину и платёжный шлюз, даже когда сервер отвечает без явной ошибки.

Пороговые уведомления

Для инфраструктурных метрик подойдут Prometheus с Grafana или более простая панель вроде Netdata; ошибки приложения удобно отправлять в Sentry или другую APM-систему. До кампании временно снизьте порог или создайте безопасное тестовое событие, чтобы проверить доставку уведомления. Лучший алерт срабатывает до того, как о проблеме написал клиент.

Чек-лист подготовки сайта к наплыву посетителей

У каждого пункта должны быть ответственный, время проверки и понятный признак успешного выполнения. Формулировка «всё настроено» не помогает, если никто не знает, где смотреть результат.

За несколько дней до запуска

• Зафиксировать базовую линию времени ответа, CPU, RAM, PHP-FPM и MySQL.
• Проверить резервную копию тестовым восстановлением: непроверенный бэкап — это пока не бэкап.
• Определить ожидаемый, пиковый и резервный сценарии трафика.
• Настроить кеширование и исключения для корзины, кабинета и оплаты.
• Проверить slow query log, внешние API и фоновые задачи.
• Провести нагрузочный тест и записать фактический предел.
• Настроить мониторинг, алерты и ответственного за реакцию.

За несколько часов

• Перенести резервное копирование, импорт и тяжёлые cron-задачи.
• Прогреть кеш и проверить, что CDN отдаёт актуальные файлы.
• Проверить свободное место на диске и ротацию логов.
• Пройти полный путь пользователя: форма, корзина, заказ, оплата, письмо.
• Подготовить план быстрого увеличения ресурсов.
• Определить, что можно временно упростить: рекомендации, тяжёлые фильтры, синхронизацию с CRM или необязательные фоновые пересчёты.

Во время кампании

• Следить за 95-м процентилем, 5xx, очередью PHP и подключениями MySQL.
• Контролировать реальные заказы, оплаты и формы, а не только доступность главной.
• Не устанавливать плагины и не вносить необязательные изменения.
• Фиксировать время, симптом и предпринятое действие при каждом отклонении.

После завершения пика

• Сопоставить поминутный трафик с графиками сервера и бизнес-событиями.
• Определить фактическое узкое место и сохранить логи.
• Повторить проблемный сценарий на staging после исправлений.
• Обновить план следующего запуска по реальным данным.
• Вернуть временно увеличенные ресурсы, если постоянной потребности в них нет.

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

Увеличение тарифа остаётся одним из инструментов, но не универсальным ответом. Если после кампании сохранить логи, графики и фактическую модель поведения посетителей, следующий запуск готовится уже не по предположениям, а по проверенным данным.

Степанов Руслан
Главред ARDinform