Un site qui tourne parfaitement bien en temps normal, mais qui ralentit nettement ou renvoie des erreurs sous forte affluence, présente souvent un symptôme précis lié au fonctionnement de PHP-FPM, le gestionnaire de processus qui exécute le code PHP de votre site à chaque requête.
Qu'est-ce que PHP-FPM concrètement
PHP-FPM (FastCGI Process Manager) est le composant qui reçoit chaque requête nécessitant d'exécuter du code PHP, et la traite via un processus dédié. Plutôt que de créer un nouveau processus à chaque requête, ce qui serait trop lent, PHP-FPM maintient un pool (groupe) de processus déjà prêts, qu'il réutilise pour traiter les requêtes au fur et à mesure qu'elles arrivent.
La notion de pool et de processus enfants (max_children)
Ce pool a une taille maximale, définie par le paramètre max_children : le nombre maximal de requêtes PHP que le serveur peut traiter simultanément pour ce site. Ce nombre est calculé en fonction de la mémoire disponible et de la mémoire moyenne consommée par chaque processus PHP du site concerné.
Que se passe-t-il quand le pool est saturé
Lorsque toutes les places du pool sont occupées par des requêtes en cours de traitement, chaque nouvelle requête entrante doit attendre en file qu'une place se libère. C'est exactement à ce moment que les visiteurs perçoivent un ralentissement net, voire une absence totale de réponse (erreur 502 ou 504) si l'attente dépasse un certain délai. Un trafic en pic, des requêtes de base de données anormalement lentes, ou un script qui bloque un processus plus longtemps que prévu sont les causes les plus fréquentes de cette saturation.
Comment réduire ces ralentissements
- Mettre en place un système de cache qui évite de solliciter PHP-FPM pour des pages qui n'ont pas changé depuis la dernière visite ;
- Optimiser les requêtes de base de données les plus lentes, qui retiennent un processus PHP plus longtemps que nécessaire ;
- Augmenter la taille du pool (max_children) sur un VPS, où vous contrôlez directement la configuration et la mémoire disponible.
Les erreurs 502 et 504, symptômes les plus visibles
Lorsque la saturation du pool PHP-FPM devient sévère, les visiteurs ne voient plus seulement un ralentissement, mais une véritable erreur affichée par le serveur web qui attendait une réponse de PHP-FPM sans jamais l'obtenir dans le délai imparti : une erreur 502 (Bad Gateway) ou 504 (Gateway Timeout). Ces codes d'erreur spécifiques, bien distincts d'une erreur 500 classique, orientent immédiatement le diagnostic vers ce composant précis plutôt que vers une erreur générale de code applicatif. Leur apparition de façon récurrente, en particulier corrélée à des pics de trafic observables dans les statistiques du site, constitue le signal le plus fiable qu'un ajustement du dimensionnement PHP-FPM est devenu nécessaire.
Le dimensionnement adéquat de PHP-FPM dépend directement de la quantité de mémoire disponible sur le serveur, ce qui relie ce réglage technique à un choix plus large de plan d'hébergement ou de VPS. Un site avec un trafic conséquent et des pages dynamiques nombreuses bénéficie mécaniquement d'un pool plus large sur un serveur disposant de davantage de mémoire vive, sans qu'aucune autre optimisation de code ne soit nécessaire pour absorber une charge plus importante. C'est une illustration concrète de la différence entre optimiser son code existant, utile mais parfois limité dans ses effets, et disposer tout simplement de davantage de ressources matérielles. Avant d'investir du temps de développement dans une optimisation poussée du code, il vaut parfois la peine de comparer ce coût à celui, souvent plus simple, d'un passage vers un plan disposant nativement de davantage de ressources allouées. Les deux approches ne s'opposent pas : un code bien optimisé sur une infrastructure correctement dimensionnée reste la combinaison la plus efficace sur le long terme.
Comment savoir si mon site souffre réellement de ce problème ?
Des ralentissements qui apparaissent spécifiquement sous forte affluence, suivis d'un retour à la normale une fois le trafic redescendu, sont le signal le plus typique d'une saturation du pool PHP-FPM.
Augmenter max_children règle-t-il toujours le problème ?
Pas toujours : si la cause réelle est une requête de base de données lente qui retient chaque processus trop longtemps, augmenter le nombre de processus disponibles ne fait que repousser temporairement la limite sans traiter la cause.
PHP-FPM concerne-t-il aussi l'hébergement mutualisé ?
Oui, mais sur un mutualisé, ce réglage est généralement géré et dimensionné par l'hébergeur plutôt que par le client, contrairement à un VPS où vous avez un contrôle direct sur cette configuration.
Pour un contrôle total sur le dimensionnement de PHP-FPM selon votre trafic réel, un VPS Linux ou un hébergement WordPress optimisé constitue la meilleure base. Pour un diagnostic de vos ralentissements actuels, contactez le support VSP TECH.
