API d'analyse des résultats

Chaque page de résultats d'un test de charge est construite à partir d'un seul document JSON : tous les échantillons de l'exécution, agrégés en percentiles, types d'erreur et synthèses par requête, par région et par palier d'utilisateurs. Ce même document est disponible pour vos propres outils via l'API d'analyse, pour qu'un tableau de bord, un générateur de rapports ou une étape de CI lise exactement les chiffres affichés sur la page de résultats.

Point d'accès

GET /api/v1/{loadtests|k6tests|jmetertests}/analysis?testrunname=<name>&testrunid=<id>

Envoyez votre clé d'API dans l'en-tête loadfocus-auth. Utilisez loadtests pour les tests cloud, k6tests pour les scripts k6 et jmetertests pour les plans JMeter. Les deux paramètres sont obligatoires ; testrunid est le numéro d'exécution visible dans l'URL des résultats.

curl -H "loadfocus-auth: $LOADFOCUS_API_KEY" \
  "https://loadfocus.com/api/v1/loadtests/analysis?testrunname=checkout-flow&testrunid=12"

Une exécution terminée est calculée une fois puis mise en cache, les appels répétés sont donc peu coûteux. Une exécution en cours renvoie ses chiffres à date.

Réponses

Le document

{
  "samples": 50312,
  "overall": {
    "mean": 212.4, "p50": 180, "p90": 410, "p95": 612, "p99": 1480,
    "min": 41, "max": 5120, "sd": 233.1, "latency": 198.7, "connect": 9.2,
    "errors": 137, "errorPct": 0.3, "rps": 83.9,
    "first": 1756540800000, "last": 1756541400000
  },
  "labels": [ { "label": "GET /api/products", "samples": 25100, "mean": 190.2, "p50": 160, "p90": 380, "p95": 540, "p99": 1200, "errors": 12, "errorPct": 0.1, "rps": 41.8, "min": 41, "max": 3100, "sd": 201.0, "latency": 180.1, "connect": 8.9 } ],
  "byThreads": [ { "vus": 50, "samples": 4210, "mean": 150.3, "max": 900, "errors": 0, "rps": 44.1, "errorPct": 0 } ],
  "byRegion": [ { "region": "us-east-1", "samples": 25156, "mean": 170.5, "p95": 480, "p99": 1100, "errors": 40, "errorPct": 0.2, "rps": 41.9 } ],
  "errorTypes": [ { "label": "POST /api/checkout", "rc": "502", "count": 90, "message": "Bad Gateway", "messages": 90, "topMessages": [ { "message": "Bad Gateway", "count": 90 } ] } ],
  "perSecond": [ { "t": 1756540800000, "samples": 62, "errors": 0, "errorPct": 0 } ],
  "histogram": { "step": 50, "buckets": [ { "from": 0, "to": 50, "count": 812 } ], "over": 31 },
  "apdex": { "t": 500, "satisfied": 44100, "tolerating": 5200, "frustrated": 1012, "score": 0.93 }
}

• samples est le nombre de requêtes enregistrées sur l'ensemble des moteurs et des régions. Tous les autres chiffres sont calculés à partir de ces échantillons, pas de moyennes par moteur.
• overall est l'exécution entière. Les temps sont en millisecondes ; latency est le temps jusqu'au premier octet, connect le temps de connexion. rps correspond aux échantillons divisés par les secondes actives de l'exécution. first et last sont des millisecondes epoch.
• labels contient une ligne par requête (URL ou nom de sampler) avec les mêmes champs plus ses propres percentiles.
• byThreads regroupe les échantillons selon le nombre d'utilisateurs virtuels actifs à ce moment-là. Lisez-le comme le temps de réponse en fonction de la charge : le palier où mean ou max décroche est votre capacité.
• byRegion contient une ligne par région cloud, pour les exécutions multi-régions.
• errorTypes contient une ligne par requête et code de statut en échec, avec le message d'erreur le plus fréquent et jusqu'à cinq topMessages.
• perSecond est le taux d'erreur dans le temps ; les longues exécutions sont ramenées à 3 600 points au maximum.
• histogram est la distribution des temps de réponse tracée sur la page de résultats, avec le nombre d'échantillons au-delà du dernier intervalle dans over.
• apdex utilise une cible de 500 ms : score vaut (satisfied + tolerating / 2) / total.

Les percentiles proviennent de 1 000 intervalles logarithmiques ; p99 est donc exact à une fraction de pour cent près et ne correspondra pas à la milliseconde à un tableur calculé sur le JTL brut.

Conditionner un pipeline

Pour une décision réussite/échec, utilisez plutôt l'API de verdict : elle applique les seuils enregistrés sur le test et renvoie un verdict, celui que lit la GitHub Action. Utilisez l'API d'analyse quand vous avez besoin des chiffres eux-mêmes, par exemple pour publier le p95 par point d'accès dans un commentaire de pull request ou tenir votre propre historique de tendances.

Connexe

• Seuils de réussite/échec
• Analyser les résultats de tests de charge
• Distribution des temps de réponse