Tuning du pool PHP-FPM en production — la décision static vs dynamic vs ondemand

Le problème de performance PHP le plus courant sur les audits entrants : PHP-FPM en mode dynamic avec un dimensionnement par défaut adapté à un VPS de 1 Go en 2014, tournant sur une machine de 16 Go, pendant que l'application meurt de faim à 5 enfants. L'autre courant : pm = ondemand sur un site prod à fort RPS qui paie le coût de fork à chaque burst.

Voici le tuning de pool que nous appliquons à l'onboarding, la discipline slowlog que nous imposons ensuite, et comment savoir si ça marche.

Le pool que nous livrons généralement

; /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 une fois que vous connaissez le bon max_children — pas de coût de fork sur les bursts, mémoire prévisible. Calculez max_children comme (RAM disponible - overhead OS - autres services) / mémoire par processus. Mesurez la mémoire par processus sous charge, pas au repos.

L'article complet couvre :

• Les modes pm — static vs dynamic vs ondemand, et quand chacun est correct
• Calculer pm.max_children à partir de la mémoire par processus observée sous charge
• pm.max_requests et pourquoi le mettre à 0 (défaut) est faux
• Tuning du slowlog — le seuil de 5 secondes et les patterns qu'il fait remonter
• Le wiring /fpm-status côté Nginx et ce que chaque métrique signifie
• Coordonner le tuning PHP-FPM avec la config OPcache + JIT sur le même hôte

Nous livrons cette configuration sur chaque stack PHP managée.