Serveur sain, utilisateur bloqué : ce que la vitesse moyenne cache

Source conceptuelle : chapitre Monitoring du Google SRE Workbook. Il explique les limites des moyennes et l’intérêt des distributions. Exemple et enquête proposés sont indépendants, pas un diagnostic de ce site ni un benchmark.

L’utilisateur se plaint, le tableau reste normal. Aucun n’a forcément tort : beaucoup de requêtes rapides peuvent masquer le rare parcours lent qu’il rencontre.

Passer du chiffre à la distribution

La moyenne éclaire certains mouvements, pas la forme de l’expérience. Je regarderais aussi percentiles, volume et erreurs. p95 marque une limite couvrant l’essentiel des observations ; ce n’est ni une promesse individuelle ni un pire cas certain.

La population compte. Écarter échecs et délais dépassés peut améliorer le graphique tout en dégradant le service. Les percentiles élevés sont aussi instables sur peu d’observations.

Une file n’est pas une utilisation CPU

Imaginons l’application en attente d’une connexion libre à la base. Le CPU peut rester faible pendant que le client attend. Proxy, pool, traitement d’arrière-plan ou fournisseur peuvent héberger la file. Un serveur plus gros ne la supprime pas forcément.

Allonger l’échéance peut simplement allonger la file. Je concevrais ensemble arrivée, capacité de traitement et réaction à la surcharge.

Suivre le parcours utilisateur

1. Choisir une action importante, recherche ou rapport.
2. Séparer durée utilisateur et durée applicative.
3. Relier attente et exécution des dépendances par identifiant.
4. Comparer un changement borné à charge semblable, erreurs et qualité comprises.

Le concept de trace OpenTelemetry aide à commencer. Mais échantillonnage et étapes non instrumentées créent des angles morts. Les événements ne doivent pas contenir inutilement des données sensibles.

Ne pas moyenner les percentiles

La moyenne des percentiles de serveurs n’est généralement pas le percentile de toutes les requêtes. L’agrégation doit correspondre aux données et à l’outil. Sachez quels parcours, période et exclusions forment la courbe.

Séparez aussi les parcours dans le reporting. Mélanger page publique légère et rapport lourd peut produire un chiffre inutile pour décider sur chacun.

Questions pratiques

Toute lenteur exige-t-elle plus de RAM ou CPU ?

Non. La capacité aide lorsque la limite est identifiée. Connexions, requêtes de base ou travail dupliqué peuvent compter davantage ; mesurez.

Un test depuis un ordinateur suffit-il ?

Il aide sur un chemin, pas à représenter appareils et réseaux variés. Combinez tests externes, données utilisateurs et observations serveur.

Quand l’enquête est-elle finie ?

Quand le même parcours s’améliore selon un critère défini, dans des conditions comparables, sans déplacer erreurs ou baisse de qualité. Une courbe verte ne suffit pas.

À lire : serveur vivant ou service réellement sain.

Sources vérifiées le 2 novembre 2026. Scénario et étapes sont une analyse originale, sans gain fixe promis ni outil recommandé.