WordPress под нагрузкой: Query Monitor и New Relic

Под нагрузкой сайт на WordPress может начать отвечать медленно задолго до того, как сервер покажет очевидную нехватку ресурсов: запросы к базе копятся, PHP-FPM исчерпывает свободные процессы, а посетители ждут. Query Monitor помогает найти проблемный запрос при разборе конкретной страницы; New Relic показывает картину по транзакциям и компонентам во времени. Ни один инструмент сам по себе не докажет, что именно сломалось первым: для этого нужны воспроизводимый тест и метрики. Разбор ориентирован на WordPress 6.x, актуальные версии Query Monitor и PHP-агента New Relic; перед установкой сверяйте совместимость с вашей версией PHP и окружением.

Почему Query Monitor не заменяет тест под нагрузкой

Query Monitor — плагин для диагностики запросов, хуков, HTTP-вызовов, ошибок PHP и других деталей текущего запроса WordPress. Он особенно полезен, когда вы уже знаете, какая страница или действие тормозит: например, открытие каталога, поиск или сохранение записи. Панель показывает, что произошло в этом выполнении, но не строит полноценную временную картину сотен параллельных запросов.

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

New Relic APM — инструмент наблюдения за приложением. PHP-агент собирает данные о транзакциях и времени, которое уходит на выполнение кода и взаимодействие с зависимостями. Это помогает увидеть повторяющиеся медленные участки и изменения во времени. Но телеметрия — не бесплатная: агент добавляет накладные расходы, а результат зависит от настроек сбора и того, насколько удачно выбраны транзакции для анализа.

Query Monitor отвечает на вопрос «что произошло в этом запросе?». New Relic помогает ответить на вопрос «что происходит с приложением по мере роста нагрузки?». Для причинно-следственного вывода нужны оба наблюдения и контрольный тест без диагностических добавок.

Что обычно упирается первым

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

• PHP-FPM и CPU. Если одновременно приходит больше работы, чем сервер успевает обработать, запросы ждут свободного рабочего процесса. Проверяйте занятость процессов, очередь и загрузку CPU вместе со временем ответа. Само по себе увеличение числа процессов может перенести проблему на память или базу.
• База данных. Повторяющиеся запросы, тяжёлые выборки или блокировки способны увеличить время ответа, даже если PHP не загружен полностью. Query Monitor помогает найти SQL-запросы, связанные с конкретной страницей; New Relic полезен для наблюдения за транзакциями и базой в динамике. Для диагноза сопоставляйте медленный запрос с его частотой и нагрузкой.
• Внешние вызовы. Платёжный шлюз, поиск, API доставки или другой сервис могут задерживать PHP-запрос. Один медленный вызов иногда удерживает рабочий процесс дольше, чем локальный код. Сверяйте время внешних обращений с общей длительностью транзакции.
• Кеширование и его обход. Главная страница может быстро отдаваться из кеша, а корзина, личный кабинет или поиск — регулярно запускать WordPress и PHP. Тест только кешируемых страниц создаёт ложное ощущение запаса мощности.

Термин: транзакция APM — обработка одного запроса приложением в терминах системы мониторинга. Названия транзакций и детализация зависят от конфигурации агента и самого приложения.

Как проводить разбор, не подменяя результат инструментом

1. Зафиксируйте сценарий. Укажите адреса и действия, которые имитирует тест: просмотр каталога, поиск, добавление в корзину. Отдельно отметьте, какие страницы кешируются, а какие обходят кеш. Проверка пройдена, если другой человек может повторить те же действия.
2. Запишите условия. Зафиксируйте версии WordPress, PHP, Query Monitor и агента New Relic, характеристики сервера, состояние кешей и настройки теста. Укажите длительность, количество параллельных пользователей и целевую частоту запросов. Проверка пройдена, если повторный прогон отличается только тем параметром, который вы намеренно меняете.
3. Снимите базовую линию без диагностических средств. Проведите тест на копии, максимально похожей на прод, без Query Monitor. Запишите время ответа, долю ошибок, загрузку CPU и памяти, состояние PHP-FPM и базы. Проверка пройдена, если у вас есть сохранённый результат, с которым можно сравнить следующие прогоны.
4. Подключите New Relic и повторите сценарий. Сопоставьте медленные транзакции с данными по PHP и зависимостям, а также с метриками сервера. Проверка пройдена, если рост задержки совпадает с конкретным участком или ресурсом, а не только с общим пиком нагрузки.
5. Разберите подозрительную страницу через Query Monitor. На тестовом окружении воспроизведите конкретное действие и проверьте SQL-запросы, HTTP-вызовы и ошибки PHP. Проверка пройдена, если подозрительный участок повторяется при одинаковом сценарии. После диагностики выключите плагин и отдельно проверьте, что он не влияет на контрольный прогон.
6. Меняйте по одному фактору. Например, проверьте эффект кеширования конкретной страницы или оптимизации найденного запроса, сохраняя остальные условия. Проверка пройдена, если улучшение повторяется в нескольких одинаковых прогонах и не сопровождается ростом ошибок.

Что сравнивать и как читать результат

Ищите совпадение нескольких сигналов. Если время ответа растёт одновременно с заполнением пула PHP-FPM, проверьте очередь и длительность транзакций. Если PHP ждёт базу, ищите конкретные запросы и состояние СУБД. Если медленен внешний вызов, отдельно проверьте его таймауты и доступность. Это направления расследования, а не универсальные доказательства.

Где измерения ломаются

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

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

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

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

Выберите один сценарий, который приносит сайту деньги или чаще всего вызывает жалобы, и измерьте его на копии продакшена. Сначала сохраните базовый прогон без Query Monitor, затем сопоставьте данные New Relic с серверными метриками и разберите конкретные запросы в Query Monitor. В проде после исправления следите за временем ответа, долей ошибок и очередью PHP-FPM: ускорение одной страницы не считается успехом, если при этом участились сбои оформления заказа.