Рекламная кампания, сезонная распродажа или запуск нового продукта меняют не только число посетителей. Они меняют набор действий: чаще открывается каталог, выполняется поиск, создаются заказы и отправляются письма. Поэтому подготовка к нагрузке начинается со сценариев, а не с покупки самого большого сервера.
Нужно понять, где система ограничена, как она ведёт себя при перегрузке и что команда сделает, если прогноз окажется ниже реального спроса.
Опишите ожидаемую нагрузку
Разделите трафик по действиям: чтение публичных страниц, поиск, вход, корзина, оформление заказа, загрузка файлов и API. Определите, какие действия требуют обращения к базе и какие можно обслуживать из кеша.
Посещаемость за сутки плохо описывает пик. Для планирования важны частота запросов, одновременные операции и доля дорогих сценариев в наиболее напряжённый период. Если данных пока мало, сформулируйте несколько проверяемых вариантов нагрузки вместо одной точной цифры без основания.
- Какие страницы получат основной трафик?
- Что посетитель должен успеть сделать?
- Какие операции нельзя потерять или выполнить дважды?
- Какой сценарий допустим при недоступности второстепенного сервиса?
Измерьте текущую работу
Соберите время ответа, долю ошибок и потребление ресурсов в обычный период. Отдельно измерьте гостевые и авторизованные запросы, быстрые ответы из кеша и обработку без кеша.
Не ограничивайтесь средним временем ответа. Перцентили p95 и p99 помогают увидеть медленную часть запросов, которую среднее значение может скрывать. Сопоставляйте их с нагрузкой, HTTP-ошибками и успешностью бизнес-операций.
Если сайт медленный уже в обычных условиях, сначала найдите причину задержки. Нагрузочный тест полезнее, когда известно исходное состояние системы.
Проверьте ограничения каждого компонента
Проследите путь запроса: веб-сервер, обработчики приложения, база, кеш и внешние сервисы. У каждого участка свои ограничения: рабочие процессы, память, соединения, блокировки, пропускная способность диска или квота API.
Увеличение числа PHP-обработчиков может повысить параллелизм, но каждый обработчик использует память и способен создать дополнительную нагрузку на базу. Согласуйте лимиты компонентов между собой, а не повышайте их по отдельности до максимума.
Проверьте свободное место и рост журналов. В пиковый период диск может заполняться быстрее обычного из-за ошибок, загрузок или очереди сообщений. Контроль места важен даже тогда, когда вычислительных ресурсов достаточно.
Подготовьте кеш и работу с базой данных
Для публичных страниц проверьте кеширование и его инвалидирование. Для WordPress полезно различать кеш страницы и кеш объектов: они решают разные задачи. Определите, какие запросы всё равно требуют полной обработки приложением.
Не кешируйте персональные ответы по правилам общих страниц. Корзина, кабинет и данные пользователя требуют корректного разделения. Перед событием проверьте и прогретый кеш, и ситуацию, когда кеш пуст или недоступен.
В базе найдите наиболее дорогие запросы, оцените блокировки и число соединений. Проверьте индексы и объём выдачи. Если один запрос просматривает лишние данные, дополнительные соединения способны усилить проблему вместо её устранения.
Проведите безопасный нагрузочный тест
Предпочтительна отдельная среда, близкая к рабочей по конфигурации и объёму данных. Исключите реальные платежи, письма клиентам и необратимые изменения. Тест рабочей системы требует согласованного окна, наблюдения и условия немедленной остановки.
- Подготовьте реалистичные сценарии и тестовые данные.
- Постепенно увеличивайте интенсивность запросов.
- Наблюдайте время ответа, ошибки, ресурсы и очереди.
- Найдите участок, после которого показатели начинают ухудшаться.
- Проверьте, возвращается ли система к нормальной работе после снижения нагрузки.
Тест только главной страницы с полным кешем не показывает готовность оформления заказа. Включите ожидаемую смесь действий и отдельные прогоны дорогих операций. Для оценки запаса фиксируйте условия теста, а не только максимальное число запросов.
Ограничьте лишнюю работу и предусмотрите деградацию
Перенесите некритичные операции в очередь, если архитектура позволяет. При этом контролируйте длину очереди, возраст старейшей задачи и повторную обработку: фоновая очередь тоже способна переполниться.
Ограничение частоты запросов помогает защитить дорогие маршруты от чрезмерного использования. Например, NGINX поддерживает limit_req. Настройки нужно проверять на реальных сценариях: пользователи за общим IP или легитимная интеграция могут попасть под слишком жёсткий лимит.
Определите, чем можно временно пожертвовать ради основной операции: отложить построение отчёта, обновление рекомендаций или обработку тяжёлого экспорта. Пользователь должен получить понятный ответ, а не бесконечное ожидание.
Подготовьте команду к пику
Назначьте ответственного за наблюдение и за изменения конфигурации. Согласуйте сигналы тревоги, действия при росте ошибок и способ остановить проблемный выпуск. Не меняйте несколько компонентов одновременно без записи, что именно сделано.
Проверьте резервные копии и восстановление, доступы и инструкции. При добавлении новой среды используйте план переключения с учётом записи данных. Перед пиком полезно ограничить несвязанные обновления, чтобы не смешивать причины возможных сбоев.
После события сравните прогноз с фактическими сценариями, запишите ограничения и обновите план. Результатом подготовки должна стать известная рабочая ёмкость системы и понятный порядок действий, когда эта граница достигнута.
Если нужна оценка готовности сайта и сервера, напишите в HOMEWEB. Укажите источник будущего трафика, критичные действия посетителей и сроки события.
Разбираете похожую ситуацию? Расскажите о ней в форме ниже — обсудим, с чего начать именно в вашем случае.
