mod_php charge l’interpréteur PHP directement à l’intérieur du processus Apache, comme un module parmi d’autres. C’est le modèle historique, celui qui a fait tourner l’essentiel des sites WordPress pendant des années sur des hébergements mutualisés à l’ancienne. Il fonctionne, il est simple à activer, mais il porte en lui des limites qui deviennent gênantes dès qu’un serveur héberge plusieurs sites aux besoins différents.
PHP-FPM (FastCGI Process Manager) répond à ces limites en séparant complètement l’exécution de PHP du serveur web. Ce changement d’architecture, progressivement généralisé sur les hébergements WordPress au cours des années 2010, mérite d’être compris dans ses raisons profondes plutôt que comme une simple mode technique.
Le fonctionnement de mod_php et ses limites
Avec mod_php, chaque processus Apache qui traite une requête embarque l’intégralité de l’interpréteur PHP, qu’il serve une page WordPress, une image statique ou un fichier CSS. Concrètement, cela signifie que la mémoire consommée par un processus Apache-mod_php gonfle mécaniquement, même pour des requêtes qui n’exécutent aucun code PHP. Sur un serveur qui gère des centaines de connexions simultanées, ce surcoût mémoire se paie cher.
Autre contrainte structurelle : mod_php impose une seule version de PHP par instance Apache. Impossible de faire cohabiter un site WordPress récent qui tourne sous PHP 7.4 et un site plus ancien qui n’accepte que PHP 5.6, sauf à multiplier les instances Apache complètes, avec la complexité de configuration que cela implique.
Ce que PHP-FPM change concrètement
PHP-FPM fonctionne comme un service indépendant, qui écoute sur un socket Unix ou un port TCP, et qui reçoit les requêtes PHP transmises par le serveur web via le protocole FastCGI. Apache ou Nginx ne font plus qu’aiguiller le trafic : dès qu’une requête concerne un fichier .php, elle est déléguée à un pool PHP-FPM dédié.
Un pool, c’est un ensemble de processus PHP configurés indépendamment, avec leur propre utilisateur système, leurs propres limites de mémoire et leur propre nombre de processus enfants. Un hébergeur peut ainsi attribuer un pool par site, avec des réglages pm.max_children et pm.max_requests adaptés au trafic réel de chaque client, sans que les sites ne se marchent dessus.
Isolation par site : pourquoi les hébergeurs y sont passés
C’est probablement l’argument qui a le plus pesé côté hébergeurs mutualisés : avec PHP-FPM, chaque pool tourne sous son propre utilisateur système. Un script compromis ou mal écrit sur un site ne peut plus lire les fichiers d’un autre site hébergé sur la même machine, à condition que les permissions du système de fichiers soient correctement posées en parallèle.
Cette isolation change aussi la donne pour la stabilité globale du serveur. Si un pool sature parce qu’un plugin WordPress mal codé multiplie les requêtes lentes, seuls les visiteurs de ce site précis en pâtissent. Avec mod_php, un pic de charge sur un site pouvait épuiser l’ensemble des processus Apache disponibles et rendre indisponibles tous les sites hébergés sur la machine, y compris ceux qui n’y étaient pour rien.
Le vrai gain : gestion fine des ressources et compatibilité multi-versions
Chaque pool PHP-FPM peut pointer vers un binaire PHP différent. Un serveur peut ainsi faire tourner en parallèle des pools en PHP 5.6, 7.2, 7.3 et 7.4, chacun associé aux sites qui en ont besoin, sans recompiler Apache ni jongler avec des instances multiples. Pour un hébergeur qui gère un parc de sites WordPress hétérogène, avec des thèmes et extensions anciens qui ne supportent pas encore les dernières versions de PHP, cette souplesse est décisive.
La gestion de la mémoire y gagne également. Les paramètres pm.max_children, pm.start_servers, pm.min_spare_servers et pm.max_spare_servers permettent de dimensionner précisément combien de processus PHP peuvent tourner simultanément pour un site donné, en fonction de la mémoire réellement disponible sur la machine.
- Isolation des processus par utilisateur système et par pool
- Coexistence de plusieurs versions de PHP sur un même serveur
- Redémarrage d’un pool sans affecter le serveur web ni les autres sites
- Réglages de mémoire et de nombre de processus propres à chaque site
Ce que ce changement ne résout pas
PHP-FPM apporte l’isolation des processus, pas l’isolation complète du système de fichiers ni celle des bases de données. Deux pools peuvent encore, selon la configuration, accéder aux mêmes répertoires si les permissions Unix n’ont pas été durcies en conséquence. L’isolation par pool est une brique parmi d’autres dans un hébergement mutualisé sécurisé, pas une solution à elle seule.
Sur nos serveurs, la bascule vers PHP-FPM a d’abord été motivée par la stabilité, bien avant la sécurité : un pool qui sature ne fait plus tomber tout le monde.
Le dimensionnement fin des pools, lui, reste un sujet à part entière : combien de processus enfants prévoir, quel mode de gestion choisir entre dynamic, static et ondemand, comment surveiller la saturation d’un pool. Ce sont des questions qui dépassent le cadre de cette explication et qui méritent un traitement dédié.
En résumé
PHP-FPM n’est pas qu’une nouveauté technique de plus : c’est un changement d’architecture qui répond à des problèmes concrets rencontrés par les hébergeurs mutualisés, l’isolation des sites entre eux et la coexistence de plusieurs versions de PHP sur une même machine. Pour un développeur WordPress qui découvre une stack serveur, comprendre cette évolution aide à interpréter correctement les fichiers de configuration qu’il croisera, qu’il s’agisse d’un www.conf de pool ou d’une directive fastcgi_pass dans un bloc Nginx.
