Un serveur web comme Nginx ne sait pas exécuter PHP. Il transmet chaque requête PHP, selon le protocole FastCGI, à un service séparé qui fait le travail et renvoie le résultat : c’est le rôle de PHP-FPM. La documentation de PHP le décrit comme l’implémentation FastCGI principale de PHP, avec des fonctions surtout utiles aux sites très sollicités. Avec Apache, PHP-FPM remplace l’ancien mod_php et s’utilise via mod_proxy_fcgi.
Comment fonctionne PHP-FPM
Un processus maître lit la configuration et gère des processus enfants, les workers, regroupés en pools. Chaque pool est défini dans un fichier de configuration, souvent un par site, avec :
useretgroup: l’identité système des processus. Deux sites dans deux pools sous deux utilisateurs différents ne peuvent pas lire les fichiers l’un de l’autre si les permissions sont correctes ;listen: l’adresse où le pool attend les requêtes, socket Unix ou adresse IP et port ;pmet ses directives : le nombre de workers ;- des valeurs PHP propres au pool, avec
php_valueouphp_admin_value. Ces dernières ne peuvent pas être modifiées parini_set()depuis un script.
Les réglages qui comptent
pm.max_children fixe le nombre maximal de workers, donc de requêtes PHP traitées en même temps. Trop bas, les visiteurs attendent ; trop haut, le serveur manque de mémoire. Une estimation simple consiste à diviser la mémoire réservée à PHP par la consommation moyenne d’un worker, mesurée sur votre site.
pm.max_requests relance un worker après un certain nombre de requêtes ; la documentation le conseille pour contourner les fuites de mémoire de bibliothèques tierces. La valeur par défaut, 0, ne relance jamais.
request_slowlog_timeout et slowlog enregistrent la pile d’appels PHP des requêtes trop lentes : un outil précieux pour trouver l’extension qui ralentit WordPress. request_terminate_timeout tue un worker bloqué quand max_execution_time ne suffit pas.
Sécurité
La documentation de PHP est catégorique : PHP-FPM ne doit jamais être joignable depuis un réseau non fiable. Un client capable d’ouvrir une connexion FastCGI contrôle la configuration de la requête, y compris auto_prepend_file, et peut donc exécuter du code arbitraire. Préférez un socket Unix quand le serveur web tourne sur la même machine, et restreignez sinon les clients autorisés avec listen.allowed_clients.
Pour WordPress
- Un pool par site sur un VPS qui héberge plusieurs WordPress : une extension compromise reste confinée à son utilisateur.
- Durcissez PHP au niveau du pool : open_basedir, désactivation des fonctions système et autres réglages de notre guide pour durcir PHP sur un hébergement. Attention, disable_functions ne peut être que complété dans un pool, pas remplacé.
- Rechargez PHP-FPM après un changement de configuration ou de version, et gardez une branche de PHP maintenue (voir les versions de PHP en fin de vie).
- Activez OPcache : il est partagé entre les workers et évite de recompiler les scripts à chaque requête.
En hébergement mutualisé, l’hébergeur règle ces pools pour vous ; seul le choix de la version et de quelques valeurs PHP vous est en général ouvert.
Erreurs fréquentes
Laisser PHP-FPM écouter sur 0.0.0.0, gonfler pm.max_children jusqu’à faire saturer la mémoire, faire tourner tous les sites dans un même pool, ou oublier de recharger le service après une modification et croire que le réglage est actif.