Як діагностувати повільні WordPress-запити через PHP-FPM slowlog

Коли PHP-FPM slowlog допомагає знайти причину

Slowlog варто використовувати, коли повільність відтворюється на рівні PHP-запиту, але її джерело не видно з access.log або стандартних логів WordPress. Це особливо корисно, якщо сторінка іноді відкривається нормально, а іноді зависає на кілька секунд.

У стеку викликів можна побачити, чи обробка зупинилася в functions.php, файлах конкретного плагіна, коді теми, REST API, AJAX-обробнику або під час запуску wp-cron.php. Лог не завжди одразу назве винну операцію, але допоможе звузити пошук до конкретної частини коду.

Важливо розуміти межі інструмента. Slowlog показує стан PHP-процесу, а не повний профіль виконання. Якщо PHP очікує відповідь від бази даних, зовнішнього API або файлової системи, у стеку буде видно місце очікування, але не обов’язково точну SQL-команду чи мережеву причину.

• сторінки мають великий TTFB без очевидного навантаження на фронтенд;
• повільність з’явилася після встановлення або оновлення плагіна;
• проблема виникає лише для REST-, AJAX- або cron-запитів;
• окремі PHP-FPM workers довго зайняті та вичерпують пул.

Як увімкнути slowlog у пулі PHP-FPM

Налаштування задають у конфігурації конкретного пулу PHP-FPM, а не в коді WordPress. Найчастіше файл пулу називається www.conf, але точний шлях залежить від дистрибутива, способу встановлення PHP та версії PHP. Перед змінами переконайтеся, що редагуєте саме пул, який обслуговує сайт.

Додайте або перевірте такі директиви:

• request_slowlog_timeout визначає, після якого часу для повільного запиту потрібно записати stack trace;
• slowlog задає шлях до файлу slow log;
• значення 3s є прикладом для діагностики, а не універсальною нормою для production.

[www]
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/www-slow.log

Підготуйте файл і права доступу

PHP-FPM має мати можливість створити або дописувати файл журналу. Якщо каталог не існує або користувач процесу не має потрібних прав, slowlog не з’явиться, навіть якщо директиви вказані правильно.

На production краще зберігати лог у спеціальному каталозі для PHP-FPM, перевірити його власника та права, а не відкривати запис для всіх користувачів. Назви користувача і групи залежать від системи.

• створіть каталог і файл, якщо вони не створюються автоматично;
• перевірте права користувача, від якого працює PHP-FPM;
• не розміщуйте лог у публічній директорії WordPress;
• переконайтеся, що на диску достатньо вільного місця.

Перевірте конфігурацію та застосуйте зміни

Після редагування конфігурації не перезапускайте службу навмання. Спочатку виконайте перевірку синтаксису PHP-FPM. Команда і її шлях можуть відрізнятися, тому орієнтуйтеся на назву встановленої служби та документацію вашої системи.

Якщо конфігурація коректна, перезавантажте або перезапустіть PHP-FPM. Для звичайного reload активні запити зазвичай не обриваються, а нові workers отримують оновлені параметри. Конкретна поведінка залежить від init-системи та конфігурації сервера.

• перевірте конфігурацію командою на кшталт php-fpm -t або відповідною командою для вашої версії PHP;
• виконайте reload служби PHP-FPM, наприклад через systemctl, використовуючи фактичну назву сервісу;
• перевірте статус служби після застосування змін;
• зробіть тестовий запит і переконайтеся, що slowlog справді оновлюється.

php-fpm -t
systemctl reload php-fpm

Як читати stack trace у slow log

У slow log зазвичай з’являється запис про процес і стек викликів, який PHP-FPM зафіксував після перевищення request_slowlog_timeout. Аналізуйте не лише останній рядок, а весь ланцюжок: він показує, який callback викликався, з якого файлу він прийшов і через які функції виконувався.

Якщо у стеку повторюються шляхи на кшталт wp-content/plugins/назва-плагіна, це сильний сигнал перевірити саме цей плагін. Якщо видно functions.php або файл теми, порівняйте проблему з активною темою та нещодавніми змінами. Для REST-запиту додатково зіставте час із endpoint і параметрами запиту.

Один stack trace не завжди доводить, що саме показаний файл є першопричиною. Код може викликати повільну базу даних, зовнішній HTTP-сервіс або блокування в іншому компоненті. Повторіть тест кілька разів і шукайте однакову ділянку стека.

• записуйте час появи проблеми та URL запиту;
• порівнюйте кілька trace, а не робіть висновок за одним випадком;
• звертайте увагу на повторювані плагіни, callback і функції;
• не редагуйте файли плагіна без резервної копії та плану відкату.

Зіставте slowlog з access.log та логами WordPress

Для коректної діагностики потрібно пов’язати stack trace з конкретним HTTP-запитом. Порівнюйте часові мітки slowlog і access.log. У access.log корисними будуть URL, HTTP-метод, статус, тривалість відповіді та, якщо налаштовано, upstream response time.

Наприклад, повільний запис для POST-запиту до wp-json може відповідати REST endpoint, тоді як тривалий GET до сторінки може бути наслідком шаблону або плагіна, який додає запити під час рендерингу. Окремо перевіряйте wp-cron.php: фонова задача може створювати навантаження без очевидного повільного відкриття сторінки для користувача.

Якщо WordPress або плагін записує власні повідомлення, зіставте їхній час зі slowlog. Так можна перевірити, чи збігається trace з імпортом, синхронізацією, генерацією зображень, відправленням HTTP-запиту або іншим процесом.

• Nginx або Apache може завершити з’єднання раніше, ніж PHP-FPM сформує повний результат;
• час у різних логах має бути синхронізований, бажано з однаковим часовим поясом;
• один повільний cron не обов’язково пояснює повільність фронтенду, якщо запити обробляються різними пулами або в різний час.

Що робити після знаходження підозрілої ділянки

Slowlog відповідає на питання «де процес перебував», але наступний крок — підтвердити гіпотезу контрольним тестом. Якщо проблема пов’язана з плагіном, перевірте сайт у staging-середовищі, тимчасово вимкнувши його або замінивши конфігурацію. На production не варто без плану деактивувати компонент, який обслуговує замовлення, авторизацію чи інші критичні функції.

Для власного коду перевірте цикли, повторні запити до бази, виклики зовнішніх API, великі вибірки та операції з файлами. Якщо trace вказує на базу даних, slowlog WordPress не замінює профілювання SQL: потрібні окремі інструменти та логи запитів, які слід вмикати обережно.

Після виправлення повторіть той самий сценарій і переконайтеся, що тривалість запиту зменшилася, а нові slowlog-записи не з’являються. Якщо повільність залишилася, перевірте інші trace та вплив паралельних запитів.

• порівняйте результат із вимкненим або оновленим компонентом;
• перевірте зовнішні API, DNS, TLS і таймаути, якщо код виконує мережеві запити;
• не збільшуйте таймаут лише для приховування проблеми;
• за потреби залучіть розробника плагіна або використайте staging для детального профілювання.

Безпека, обсяг логів і вимкнення після діагностики

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

Після завершення діагностики збільште request_slowlog_timeout до значення, яке фіксує лише справді підозрілі запити, або вимкніть slowlog, якщо постійний контроль не потрібен. Організуйте logrotate чи інший механізм ротації, щоб файл не заповнив диск.

Перед вимкненням збережіть потрібні записи та зафіксуйте, які зміни дали результат. Це спростить повторне розслідування після майбутнього оновлення WordPress, теми або плагіна.

• обмежте доступ до slowlog на рівні файлової системи;
• налаштуйте ротацію, стиснення та строк зберігання;
• контролюйте вільне місце на сервері;
• після діагностики виконайте reload PHP-FPM і перевірте нову поведінку.