Tuning del pool de PHP-FPM en producción — la decisión static vs dynamic vs ondemand

El problema de rendimiento de PHP más común en auditorías entrantes: PHP-FPM en modo dynamic con un dimensionamiento por defecto apropiado para un VPS de 1 GB en 2014, corriendo en una caja de 16 GB, mientras la aplicación se muere de hambre con 5 hijos. El otro común: pm = ondemand en un sitio de producción con alto RPS que paga el coste de fork en cada ráfaga.

Este es el tuning de pool que aplicamos en el onboarding, la disciplina de slowlog que imponemos después, y cómo saber si está funcionando.

El pool que solemos entregar

; /etc/php/8.3/fpm/pool.d/www.conf
pm = static
pm.max_children = 50
pm.max_requests = 1000
 
request_terminate_timeout = 60s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
 
pm.status_path = /fpm-status
ping.path = /fpm-ping

static una vez que conoces el max_children correcto — sin coste de fork en ráfagas, memoria predecible. Calcula max_children como (RAM disponible - overhead del SO - otros servicios) / memoria por proceso. Mide la memoria por proceso bajo carga, no en reposo.

El artículo completo cubre:

• Los modos pm — static vs dynamic vs ondemand, y cuándo cada uno está bien
• Calcular pm.max_children desde la memoria por proceso observada bajo carga
• pm.max_requests y por qué ponerlo en 0 (default) está mal
• Tuning del slowlog — el umbral de 5 segundos y los patrones que saca a la luz
• El cableado de /fpm-status en Nginx y qué significa cada métrica
• Coordinar el tuning de PHP-FPM con la config de OPcache + JIT en el mismo host

Entregamos esta configuración en cada stack PHP gestionada.