La bonne métrique n'est pas celle qui s'affiche

Le temps de réponse est la métrique qu'on affiche partout. Sur un serveur qui n'exécute qu'une chose à la fois, c'est aussi celle qui ment le plus élégamment : elle mesure ce que la requête a vécu, pas ce que les autres ont attendu.

1. Le mot qui décide de tout

Notre serveur stocke ses données dans une base intégrée, en mode synchrone. Ce mot signifie qu'il n'y a ni file d'attente, ni parallélisme : chaque requête vers la base bloque le fil d'exécution unique du programme, du début à la fin.

Tant que les requêtes durent moins d'une milliseconde, ça ne se voit pas — et c'est précisément le piège. Le comportement est excellent jusqu'au moment exact où il devient catastrophique, sans zone de transition qui préviendrait.

Une seule requête lente ne ralentit pas son appelant : elle met tout le monde en attente, y compris la page qui sert à savoir si le service va bien. Cette page-là répondra tard, et pour la même raison que les autres — ce qui la rend inutile au moment précis où on en a besoin.

2. Ce que le temps de réponse ne dit pas

Prenons une requête traitée en deux millisecondes. C'est un excellent chiffre, et il est exact. Mais il ne dit pas combien de temps elle a patienté avant d'être traitée, ni combien d'autres patientaient derrière elle pendant qu'elle occupait le fil.

La moyenne aggrave le malentendu : quelques requêtes très lentes noyées dans des milliers de rapides donnent une moyenne rassurante. Les centiles élevés — la valeur au-dessous de laquelle se trouvent 95 % ou 99 % des requêtes — corrigent une partie du problème, mais restent des mesures par requête. Or le mal n'est pas dans la requête. Il est dans le fil.

3. La mesure qui répond

On mesure donc le retard de la boucle d'événements. Le principe tient en une phrase : on demande au programme de se rappeler dans exactement dix millisecondes, et on regarde combien de temps il a effectivement mis à revenir.

S'il revient à dix, il n'était occupé par rien. S'il revient à quarante, il a passé trente millisecondes ailleurs — et pendant ces trente millisecondes, aucune requête n'avançait. Ce chiffre-là ne dépend d'aucun appelant. Il décrit l'état de la machine, pas celui d'un client.

C'est aussi la mesure qui indique quoi corriger. Un temps de réponse élevé peut venir du réseau, du client, d'un service tiers. Un retard de boucle élevé ne peut venir que d'une chose : du travail synchrone qu'on s'inflige à soi-même.

4. Ce qu'on en a tiré comme protections

La mesure a orienté les défenses, dans cet ordre : refuser vite au-delà d'un certain nombre de requêtes en vol, plutôt que d'allonger une file invisible ; limiter le débit par identité, pour absorber les rafales normales et couper le matraquage ; et mettre en cache quelques secondes les lectures répétées, parce qu'une carte animée qui interroge le serveur soixante fois par seconde demande soixante fois la même chose.

Sous une rafale de trois cents requêtes simultanées, deux cent vingt ont été refusées par la limitation de débit, et aucune par la saturation. Ce zéro est le chiffre le plus utile de la série : il dit que la protection la moins coûteuse coupe en premier, et que la plus brutale reste en réserve. Sans mesure de la boucle, on n'aurait su ni régler l'ordre, ni vérifier qu'il tenait.

🔭