Métriques de performance d'API : latence, débit, taux d'erreur

Que sont les métriques de performance d'API ?

Les métriques de performance d'une API mesurent la rapidité de ses réponses, le trafic qu'elle absorbe et la fréquence de ses échecs, sur du trafic réel ou lors d'un test. Les quatre principales sont la latence, le débit, le taux d'erreur et la saturation. Les équipes s'en servent pour fixer des objectifs, repérer les goulots d'étranglement et décider quand passer à l'échelle.

Les quatre signaux d'or

Le livre SRE de Google nomme quatre signaux qui couvrent l'essentiel de ce qu'il faut surveiller sur un service (voir Monitoring Distributed Systems, en anglais). Les valeurs d'exemple sont purement illustratives.

Latence : des percentiles, pas la moyenne

La moyenne cache la queue lente. Le livre SRE donne le cas classique : un service avec une latence moyenne de 100 ms à 1 000 requêtes par seconde peut très bien avoir 1 % de requêtes qui prennent 5 secondes. Rapportez donc des percentiles ; plus de détails dans pourquoi les percentiles sont plus utiles que les moyennes (article en anglais).

Mesurez séparément la latence des requêtes réussies et des requêtes en échec. Une erreur rapide peut embellir vos chiffres par rapport à l'expérience réelle, et une erreur lente est pire qu'une erreur rapide. Les bases : latence.

Débit

Le débit est la quantité de travail effectuée par unité de temps ; pour une API, ce sont généralement des requêtes par seconde (RPS). Les grandeurs voisines sont les utilisateurs simultanés (utilisateurs virtuels dans un test) et la bande passante. Seul, le débit dit peu de choses : lisez-le avec la latence et les erreurs. Le point où la latence grimpe alors que le débit cesse de croître est votre capacité pratique ; voir le lien entre débit et temps de réponse (en anglais).

Taux d'erreur

La part des requêtes qui échouent. Découpez-la par cause, car chacune mène ailleurs :

• Réponses 5xx : pannes côté serveur, c'est votre problème.
• Réponses 4xx : surtout des erreurs du client (401, 404, 429), mais un pic soudain peut signaler une version défectueuse ou un identifiant expiré.
• Délais dépassés et erreurs de connexion : la requête ne s'est jamais terminée.
• Contenu erroné avec un code 200 : le livre SRE compte aussi cela comme une erreur. Vérifiez le corps de la réponse, pas seulement le code de statut.

Saturation

La saturation montre à quel point le système est proche de sa limite. Beaucoup de systèmes ralentissent bien avant 100 % d'utilisation. Surveillez le CPU, la mémoire, les E/S disque, le réseau, l'usage du pool de connexions à la base de données et la longueur des files, et fixez un objectif d'utilisation. Un p99 qui monte sur une fenêtre courte est souvent le premier signe.

Autres temps utiles

• Time to first byte : le temps de traitement du serveur avant le début de la réponse, voir Time to First Byte (TTFB).
• Temps DNS, connexion TCP et TLS : surcoût réseau avant même que votre code s'exécute.
• Temps de téléchargement : taille de la réponse et bande passante.
• Détail par endpoint et par région : un chiffre global peut masquer un endpoint ou une région lents.

SLI, SLO, SLA et budget d'erreur

Les 43 minutes viennent d'un calcul simple : 0,1 % d'un mois de 30 jours (43 200 minutes). Plus sur les contrats dans gestion des SLA.

Un exemple chiffré

Imaginons un test de charge sur un endpoint hypothétique /orders avec 50, 100 puis 200 utilisateurs virtuels. À 50 et 100 utilisateurs, le p95 reste autour de 180 ms et les erreurs sont quasi nulles. À 200 utilisateurs, le p95 saute à 900 ms et 2 % des requêtes expirent, alors que le débit n'a presque pas progressé par rapport au test à 100 utilisateurs. Le point de rupture se situe vers 100 utilisateurs : c'est votre capacité sûre, et le pool de connexions à la base de données (une métrique de saturation) est la première chose à examiner.

Comment mesurer la performance d'une API

• Tests de charge : génèrent un trafic contrôlé avant une release et permettent de comparer les exécutions. Voir test de charge.
• Surveillance synthétique d'API : des vérifications planifiées sur la production qui enregistrent temps de réponse, statut et corps. Voir surveillance d’API.
• APM et données d'utilisateurs réels : l'instrumentation côté serveur et les données de terrain montrent ce que vit le trafic réel. Voir supervision des performances applicatives.

Aucune source ne voit tout : les tests donnent une baseline reproductible, la surveillance détecte les régressions en production et l'APM en explique la cause.

Erreurs fréquentes

• Ne rapporter que des moyennes. La queue lente, c'est ce dont les utilisateurs se plaignent.
• Mesurer seulement en préproduction. Données, caches et profil de trafic diffèrent en production.
• Aucun objectif. Des métriques que personne ne compare à un SLO sont ignorées.
• Alerter sur chaque 5xx. Alertez plutôt sur le taux d'erreur sur une fenêtre.
• Un seul chiffre pour tous les endpoints. Détaillez par endpoint et par version.
• Ne tester qu'une fois. Retestez après les changements importants.

Mesurer la performance de votre API avec LoadFocus

Le test de charge de LoadFocus exécute des tests JMeter, k6 et sans code depuis 25 régions cloud et rapporte temps de réponse, latence, débit, erreurs et les percentiles 50, 90 et 99, avec des seuils de réussite ou d'échec sur p95 ou p99, taux d'erreur et débit. La surveillance d’API contrôle vos endpoints selon un calendrier (toutes les 5 minutes avec l'offre gratuite) et peut faire échouer un contrôle selon le statut, le corps, les en-têtes ou le temps de réponse. Pour une vue plus large, voir test d’API.

Questions fréquentes : métriques de performance d'API

Quelle est une bonne latence pour une API ?

Cela dépend du cas d'usage et de ce qu'attendent les utilisateurs. Beaucoup d'équipes visent un p95 de quelques centaines de millisecondes pour les endpoints interactifs, et moins pour les appels internes ou temps réel. Fixez l'objectif à partir de vos propres utilisateurs et mesurez p95 et p99, pas la moyenne.

Comment trouver le débit maximal d'une API ?

Lancez un test de charge qui augmente le trafic par paliers et observez la latence et les erreurs. Le point où la latence grimpe ou où les erreurs apparaissent alors que le débit cesse de croître est le maximum pratique.

Quel taux d'erreur est acceptable ?

Il n'existe pas de chiffre universel. Il découle de votre SLO : un endpoint de paiement ou de connexion exige un taux bien plus bas qu'un endpoint non critique. Définissez-le par endpoint et mesurez-le sur une fenêtre comme 30 jours.

Faut-il suivre le p95 ou le p99 ?

Les deux. Le p95 décrit la qualité pour la plupart des utilisateurs, le p99 l'expérience des moins chanceux. Avec beaucoup de trafic, même 1 % représente beaucoup de monde.

Qu'est-ce qu'un budget d'erreur ?

La quantité d'échec que votre SLO autorise encore. Avec 99,9 % de disponibilité sur 30 jours, cela fait environ 43 minutes. Quand le budget est presque épuisé, les équipes freinent en général les releases risquées et traitent d'abord la fiabilité.