19h00, un vendredi : le trafic d’un site d’actualité régional passe de 800 à 2 600 visiteurs simultanés en moins d’une heure, porté par une actualité nationale relayée massivement sur les réseaux sociaux sans qu’aucun signal n’ait permis de l’anticiper la veille. Aucune refonte d’architecture n’est possible dans ce délai : la seule question qui compte est de savoir quels leviers peuvent être actionnés dans les minutes qui suivent, avec l’infrastructure existante.
Premier réflexe : vérifier le cache de page
Le cache de page complet (via une extension comme WP Rocket, W3 Total Cache, ou un cache serveur type FastCGI cache sur nginx) reste le levier le plus efficace en urgence, car il évite qu’une majorité des requêtes n’atteigne PHP-FPM et la base de données. Sur ce projet, le cache FastCGI de nginx était actif, mais avec une durée de validité de seulement soixante secondes, insuffisante pour absorber un pic aussi brutal.
fastcgi_cache_valid 200 10m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
Allonger temporairement cette durée de validité, même au prix d’un contenu légèrement moins frais pendant quelques minutes, réduit immédiatement et considérablement la charge sur les couches applicatives.
Deuxième levier : les workers PHP-FPM
Le nombre de processus enfants PHP-FPM (pm.max_children) limite le nombre de requêtes dynamiques traitées simultanément. Une augmentation ponctuelle de ce paramètre, appliquée à chaud sans redémarrage complet du service via un rechargement, permet d’absorber davantage de requêtes non couvertes par le cache, dans la limite de la mémoire disponible sur le serveur.
; www.conf
pm.max_children = 40 ; contre 15 en configuration normale
sudo systemctl reload php8.1-fpm
Attention à la mémoire disponible
Augmenter ce chiffre sans vérifier la RAM disponible expose à un risque inverse : le système d’exploitation peut déclencher l’OOM killer si la mémoire vient à manquer, aggravant l’incident plutôt que de le résoudre. Une vérification rapide via free -h avant d’ajuster ce paramètre reste indispensable, même dans l’urgence.
Troisième levier : désactiver le superflu
- Désactiver temporairement les widgets dynamiques non essentiels (compteurs de vues en temps réel, recommandations personnalisées) qui génèrent des requêtes non cachables
- Basculer les commentaires vers un chargement différé plutôt qu’un affichage immédiat sur chaque page
- Vérifier qu’aucun robot d’indexation agressif ne s’ajoute au pic légitime au même moment
Quatrième levier : la base de données en lecture
Si une réplique en lecture existe déjà sur l’infrastructure, basculer temporairement les requêtes de lecture non critiques (affichage des articles, recherche) vers cette réplique soulage l’instance principale, qui reste alors disponible pour les écritures (commentaires, mises à jour éditoriales en cours). Cette bascule, si elle n’a pas été préparée à l’avance dans le code applicatif, reste difficile à improviser en urgence : elle doit idéalement être anticipée en amont via un plugin de répartition de charge de lecture.
Ce qu’il ne faut pas faire dans l’urgence
- Redémarrer le serveur de base de données en espérant un effet positif, ce qui coupe généralement toutes les connexions actives sans résoudre la cause
- Augmenter démesurément les workers PHP-FPM sans vérifier la mémoire disponible, au risque de déclencher l’OOM killer
- Modifier le code applicatif à chaud sans test préalable, un risque bien supérieur au bénéfice attendu en pleine affluence
Après l’incident
Une fois le pic retombé, documenter précisément ce qui a été modifié à chaud — durée de cache, nombre de workers, widgets désactivés — permet de préparer une configuration de secours prête à activer en quelques secondes lors du prochain pic, plutôt que d’improviser à nouveau sous pression.
Un pic de trafic ne prévient jamais ; ce qui distingue un incident maîtrisé d’un site indisponible, c’est d’avoir déjà identifié à froid les trois ou quatre leviers à actionner en premier.
En résumé
Face à un pic de trafic soudain, le cache de page reste le premier réflexe, suivi d’un ajustement temporaire des workers PHP-FPM et de la désactivation du superflu non cachable. Aucun de ces leviers ne demande de refonte d’architecture : ils s’activent en quelques minutes, à condition de les avoir identifiés avant que l’urgence ne s’impose.
