Quatre week-ends d’affilée, la même erreur : une page blanche suivie d’un 502 Bad Gateway, systématiquement entre 10 heures et midi, jamais en semaine. Le site d’un office de tourisme de moyenne montagne présente ce schéma de panne récurrent depuis le début de la saison, à chaque pic de fréquentation touristique du week-end.
Une panne qui se répète selon un motif aussi net n’est pas un hasard : c’est un signal de dimensionnement. Contrairement à un incident isolé, ce type de récurrence permet d’observer le comportement du serveur au moment précis où il commence à faiblir, ce qui change complètement l’angle du diagnostic.
Ce que montrent les journaux au moment de la panne
Les journaux Nginx pour la période concernée affichent des erreurs de type upstream timed out et connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable). Cette dernière erreur, en particulier, pointe directement vers un épuisement du pool PHP-FPM : le serveur PHP n’accepte plus de nouvelles connexions parce que tous ses processus enfants sont déjà occupés.
- Erreur
502 Bad Gatewaycôté Nginx, jamais côté PHP directement - Message
Resource temporarily unavailabledans le journal PHP-FPM - Corrélation exacte avec les créneaux de forte fréquentation touristique
Vérifier le dimensionnement réel du pool PHP-FPM
La configuration du pool, sur ce mutualisé, limitait le nombre maximal de processus enfants à une valeur bien inférieure à ce que le trafic de pointe exigeait. Le fichier de configuration du pool concerné révélait le problème dès la première lecture :
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
Cinq processus enfants au maximum, pour un site qui reçoit, aux heures de pointe du week-end, plusieurs dizaines de requêtes simultanées liées à la consultation du calendrier des hébergements et des activités. Dès que la sixième requête arrive alors que les cinq processus sont occupés, elle se met en attente, puis finit par expirer côté Nginx, qui renvoie un 502 au visiteur.
Un mutualisé n’est pas automatiquement en cause
Un point mérite d’être souligné : le problème ne venait pas du fait que l’hébergement soit mutualisé, mais du fait que le pool PHP-FPM alloué n’avait jamais été ajusté au trafic réel du site. Beaucoup d’offres mutualisées modernes permettent d’ajuster ces paramètres, ou proposent des paliers de ressources supérieurs sans nécessiter de migration vers un VPS.
Avant de conclure qu’un hébergement mutualisé « ne suffit plus », il vaut mieux vérifier ce qui a réellement été configuré. Un pool PHP-FPM sous-dimensionné produit exactement les mêmes symptômes qu’un hébergement trop faible, pour un coût de correction sans commune mesure.
Les ajustements appliqués
L’hébergeur a accepté de relever les limites du pool sur ce compte, sans changement d’offre :
pm.max_childrenporté à 15, en cohérence avec la mémoire disponible sur l’offre souscrite- Activation d’un cache de pages complet côté WordPress, pour réduire le nombre de requêtes PHP réellement exécutées
- Mise en place d’une surveillance simple du taux d’utilisation du pool, consultable dans les journaux
Avec un cache de pages actif, la majorité des visiteurs consultant le calendrier ne déclenchent plus d’exécution PHP à chaque requête, ce qui réduit mécaniquement la pression sur le pool, même sans toucher à sa taille.
Distinguer une panne de dimensionnement d’une vraie surcharge
Un point mérite d’être précisé avant de conclure trop vite qu’un serveur est sous-dimensionné : le trafic mesuré lors des pics, une fois consolidé, restait très modeste au regard de ce qu’un serveur mutualisé récent peut absorber. Quelques dizaines de visiteurs simultanés ne devraient jamais suffire à saturer un hébergement correctement réglé. C’est bien la configuration par défaut du pool, héritée d’une offre pensée pour des sites à trafic constant et faible, qui expliquait l’essentiel du problème.
- Trafic de pointe mesuré autour de quarante visiteurs simultanés, un volume modeste en absolu
- Pool limité à cinq processus, calibré pour un site sans pic particulier
- Absence totale de cache de pages avant l’intervention, chaque requête déclenchant une exécution PHP complète
Ce que ce dossier change pour les prochains projets similaires
Un site à trafic saisonnier et concentré sur des créneaux précis mérite un dimensionnement pensé pour le pic, pas pour la moyenne. Vérifier la configuration du pool PHP-FPM en amont, activer un cache de pages adapté au contenu, et surveiller les journaux pendant les premières semaines de forte affluence permettent d’éviter une panne qui, sur ce dossier, s’est répétée quatre semaines avant d’être enfin corrigée.
