PHP-FPM чаще всего тормозит WordPress не сам по себе, а из-за неверной настройки пула

PHP-FPM чаще всего тормозит WordPress не сам по себе, а из-за неверной настройки пула

PHP-FPM — это не «ускоритель», а менеджер воркеров. Если воркеров мало, очередь запросов растёт; если слишком много — память утекает в свап и сайт снова тормозит. Для WordPress это особенно заметно на пиках: админка открывается рывками, а фронт начинает ждать свободный процесс.

Проверьте три вещи:
— pm.max_children: хватает ли процессов на одновременные запросы
— pm.max_requests: не копятся ли утечки в долгоживущих воркерах
— memory_limit и реальную RAM: один воркер может съедать заметно больше, чем кажется по конфигу

Типичная ошибка — ставить pm.max_children «с запасом» без расчёта памяти. Если каждый процесс в среднем ест 80–120 МБ, а на сервере мало RAM, FPM начнёт конкурировать с MySQL, Redis и самим web-сервером. В итоге сайт медленнее при большем числе процессов.

Ещё один полезный приём — включить slowlog и смотреть, какие запросы реально держат воркеры. Часто виноват не PHP-FPM, а тяжёлый плагин, медленный внешний API или кривой SQL.

Если WordPress «тупит» под нагрузкой, сначала измерьте среднее потребление одного воркера и только потом увеличивайте пул: в PHP-FPM побеждает не самый большой лимит, а самый трезвый расчёт.