Un rapport de 3,4 entre le trafic de l’heure la plus chargée de la journée et la moyenne horaire calculée sur vingt-quatre heures : c’est ce qu’a révélé l’analyse menée après plusieurs ralentissements ponctuels signalés par un client, malgré un serveur dimensionné, sur le papier, largement au-dessus de son trafic moyen quotidien.
Ce billet détaille cet antipattern de dimensionnement, rencontré fréquemment lors de la reprise de serveurs déjà en production : la moyenne de trafic, chiffre rassurant en apparence, masque des écarts réguliers qui suffisent à saturer un serveur pourtant correctement dimensionné selon ce seul critère. Les solutions d’autoscaling automatique restent hors du périmètre de ce billet, qui se concentre sur le diagnostic du problème lui-même.
Ce qu’on observe : un serveur qui ralentit sans jamais paraître surchargé
Le tableau de bord de supervision de ce serveur affichait, sur la durée, une charge processeur moyenne raisonnable, une consommation mémoire stable, et un nombre de requêtes par seconde apparemment bien en deçà de la capacité théorique du serveur. Rien, dans les métriques agrégées sur la journée ou la semaine, ne laissait supposer un dimensionnement insuffisant.
Pourtant, le client signalait des ralentissements réguliers, toujours aux mêmes heures : entre midi et quatorze heures, un site de restauration recevait un afflux de commandes en ligne concentré sur ce créneau précis, largement supérieur au reste de la journée. Le serveur, dimensionné sur la moyenne journalière, se retrouvait sous-capacité précisément pendant cette fenêtre récurrente.
Pourquoi c’est un problème structurel, pas un incident isolé
Le dimensionnement sur la moyenne suppose implicitement un trafic relativement constant dans le temps, une hypothèse rarement vérifiée en pratique sur un site avec une activité commerciale ou éditoriale marquée par des habitudes horaires régulières. Un site de restauration a ses pics de commande, un site d’actualité ses pics de consultation après une publication, un site scolaire ses pics d’inscription à date fixe.
- Une moyenne calculée sur vingt-quatre heures dilue mathématiquement un pic de deux heures dans un total de faible amplitude apparente, même si ce pic sature réellement le serveur pendant sa durée.
- Un dimensionnement qui se contente d’un coefficient de marge appliqué à la moyenne (par exemple « deux fois la moyenne observée ») reste vulnérable si le rapport réel entre pic et moyenne dépasse ce coefficient choisi arbitrairement.
- Le problème se reproduit à l’identique tant que la métrique de dimensionnement retenue reste la moyenne, quelle que soit la marge de sécurité appliquée au-dessus.
Quoi faire : mesurer la variance avant de dimensionner
Le correctif ne consiste pas simplement à augmenter la capacité du serveur, mais à changer la métrique de référence utilisée pour le dimensionnement. Plutôt que la moyenne journalière, l’analyse s’est appuyée sur le trafic de l’heure la plus chargée, observée sur plusieurs semaines consécutives, afin de vérifier la régularité du phénomène plutôt que de réagir à un pic ponctuel isolé.
| Métrique retenue | Valeur observée | Pertinence pour le dimensionnement |
|---|---|---|
| Moyenne journalière de requêtes | Référence initiale utilisée | Masque les pics horaires réguliers |
| Pic horaire moyen sur quatre semaines | 3,4 fois la moyenne journalière | Reflète la charge réelle à absorber |
| Pic horaire maximal observé (jour exceptionnel) | Ponctuel, non représentatif du régime courant | Utile pour une marge de sécurité complémentaire, pas comme référence unique |
Le nouveau dimensionnement retenu
Le serveur a été redimensionné pour absorber confortablement le pic horaire moyen observé sur quatre semaines, avec une marge additionnelle raisonnable au-dessus, plutôt qu’un multiple arbitraire de la moyenne journalière. Cette approche a nécessité davantage de ressources que le dimensionnement initial, un coût que le client a accepté une fois le lien direct établi entre le ralentissement observé et le pic de commandes de son activité réelle.
Une moyenne rassure toujours plus qu’elle n’informe ; c’est précisément pour cela qu’elle constitue une base de dimensionnement dangereuse si elle reste la seule métrique consultée.
En résumé
Dimensionner un serveur WordPress sur sa moyenne de trafic revient à ignorer la variance réelle de l’activité qu’il héberge, une variance souvent liée à des habitudes horaires prévisibles et récurrentes plutôt qu’à un hasard imprévisible. Mesurer le rapport entre le pic horaire régulier et la moyenne journalière, avant de fixer une capacité serveur, évite de découvrir ce rapport a posteriori, au moment où le client signale un ralentissement que les métriques agrégées ne laissaient pourtant rien deviner.
