WordPress под нагрузкой: что значат 10 тысяч посетителей в час

10 тысяч посетителей в час — в среднем около 2,8 посетителя в секунду, но эта цифра почти ничего не говорит о нагрузке на WordPress. Один человек может открыть одну страницу, а может запустить десятки запросов к серверу; кроме того, весь поток способен прийти за несколько минут. Для разбора важнее количество динамических запросов в пике, доля кешированных страниц и поведение сайта при одновременных действиях.

Сначала переведите посетителей в запросы

Посетитель — не единица нагрузки. Браузер загружает страницу и её ресурсы, но изображения, CSS и JavaScript обычно можно отдавать как статические файлы. PHP и база данных включаются прежде всего тогда, когда нужно сформировать динамическую страницу или обработать действие пользователя. Если перед WordPress настроен полно-страничный кеш, повторный запрос к публичной странице может вообще не запускать PHP.

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

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

Что происходит внутри WordPress

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

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

Кеш объектов^* — слой, который сохраняет результаты вычислений или запросов WordPress, чтобы повторно получать их без той же работы. Для постоянного хранения между запросами нужна подходящая инфраструктура; наличие такого слоя не отменяет проверки корректности данных.

Как найти узкое место без выдуманных нормативов

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

1. Зафиксируйте сценарии. Проверьте главную, страницу записи, поиск, карточку товара и оформление заказа — только те маршруты, которые действительно есть на сайте. Успех: вы знаете, какие запросы кешируются, а какие каждый раз доходят до приложения.
2. Снимите базовые метрики. Запишите время ответа, долю ошибок, загрузку CPU и памяти, занятость PHP workers и время запросов к базе. Успех: для каждого сценария есть исходные данные и временной интервал, а не только среднее за день.
3. Создайте реалистичный пик на тестовой копии. Увеличивайте параллельность постепенно и проверяйте, совпадает ли поведение теста с ожидаемым потоком пользователей. Успех: видны момент роста задержек, первые ошибки и ресурс, который первым упирается в предел.
4. Сравните кешированные и динамические запросы. Проверьте заголовки ответа и логи сервера: попадает ли публичная страница в кеш, а приватная — нет. Успех: вы понимаете, какая доля нагрузки обходит кеш и почему.
5. Повторите тест после одного изменения. Например, отключите тяжёлый плагин на копии или исправьте медленный запрос. Успех: улучшение видно в тех же сценариях, а не только в субъективном ощущении скорости.

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

В логах ищите не только ошибки WordPress. Проверьте ответы веб-сервера, журнал PHP и медленные запросы базы данных. Если задержка начинается до входа запроса в PHP, причина может быть в соединениях или очередях на уровне сервера; если PHP занят, ищите дорогие хуки, плагины и внешние вызовы. Если серверная часть отвечает быстро, а страница всё равно долго отображается, измеряйте загрузку ресурсов в браузере.

Где кеширование даёт сбой

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

Тестовая нагрузка тоже может обмануть. Если генератор создаёт только запросы к одной главной странице, он не проверит поиск, базу, корзину и интеграции. Если все запросы идут с одного адреса, ограничения по частоте могут исказить результат. Наконец, тест на пустой базе не покажет, как поведёт себя каталог с реальным объёмом записей.

Что делать дальше

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

Отдельный вопрос — стратегия инвалидации кеша при обновлении контента; здесь рассматриваем только её влияние на нагрузку.

^* Термин: кеш объектов WordPress — механизм повторного использования сохранённых данных приложения; конкретное поведение зависит от настроенного кеширующего слоя и конфигурации сайта.