Débit (throughput)

Le débit (throughput) est la quantité de travail qu’un système réalise par unité de temps : requêtes par seconde (RPS) pour une API, transactions par seconde (TPS) pour un système de paiement, messages par seconde pour un consommateur de file. Il mesure la capacité, tandis que la latence mesure le temps nécessaire à chaque unité de travail. Il faut les deux, plus le taux d’erreur, pour décrire la performance.

Le lien entre débit, latence et concurrence

Pour un système en régime stable, la loi de Little relie les trois :

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

Avec des utilisateurs virtuels qui marquent une pause entre leurs actions, le temps de réflexion s’ajoute au cycle : débit ≈ utilisateurs ÷ (temps de réponse + temps de réflexion). Ainsi, 100 utilisateurs avec un temps de réponse de 0,5 s et 4,5 s de temps de réflexion génèrent environ 20 requêtes par seconde, pas 100. C’est pourquoi « nous avons testé avec 1 000 utilisateurs » ne veut pas dire grand-chose tant que vous n’indiquez pas aussi le temps de réflexion et le débit de requêtes obtenu.

L’allure du débit quand la charge augmente

Quand la charge augmente, le débit commence par suivre. À un moment, une ressource sature (CPU, pool de connexions, composant mono-thread) : le débit plafonne tandis que la latence grimpe en flèche. Si l’on pousse encore, le débit peut même baisser, car le système consacre ses efforts aux files d’attente, aux nouvelles tentatives et aux timeouts. Trouver ce plateau est le principal résultat d’un test de stress, et il définit la capacité pratique.

Conseils de test

• Exprimez les objectifs en débit plus latence. « 500 RPS avec un p95 sous 300 ms et moins de 1 % d’erreurs » est testable. « Supporte un trafic élevé » ne l’est pas.
• Ne comptez que le travail réussi. Un serveur qui répond à 2 000 RPS dont la moitié en erreur 500 ne fournit pas 2 000 RPS de travail utile.
• Utilisez une charge par taux d’arrivée quand c’est possible. Générer un débit de requêtes fixe montre directement si le système peut le soutenir ; un pool fixe d’utilisateurs enverra discrètement moins de requêtes à mesure que les réponses ralentissent.
• Surveillez le générateur de charge. Si la machine qui exécute le test est à 100 % de CPU, vous avez mesuré le débit du générateur, pas celui du système.
• Attention aux limites de débit. Une passerelle qui renvoie 429 plafonne le débit mesuré ; décidez si vous testez le limiteur ou le service qui se trouve derrière.