Ergebnisanalyse-API

Jede Ergebnisseite eines Lasttests entsteht aus einem JSON-Dokument: alle Samples des Laufs, aggregiert zu Perzentilen, Fehlertypen sowie Rollups pro Request, pro Region und pro Nutzerstufe. Dasselbe Dokument steht Ihren eigenen Werkzeugen über die Analyse-API zur Verfügung, sodass ein Dashboard, ein Reportgenerator oder ein CI-Schritt genau die Zahlen liest, die die Ergebnisseite zeigt.

Endpunkt

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

Senden Sie Ihren API-Schlüssel im Header loadfocus-auth. Verwenden Sie loadtests für Cloud-Tests, k6tests für k6-Skripte und jmetertests für JMeter-Pläne. Beide Query-Parameter sind Pflicht; testrunid ist die Laufnummer aus der Ergebnis-URL.

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

Ein abgeschlossener Lauf wird einmal berechnet und zwischengespeichert, wiederholte Aufrufe sind daher günstig. Ein noch laufender Test liefert seine bisherigen Zahlen.

Antworten

Status	Body	Bedeutung
`200`	das Analyse-Dokument	Der Lauf existiert und hat Samples.
`404`	`{ "error": "no-data" }`	Unbekannter Lauf, Lauf eines anderen Teams oder noch keine Samples.
`503`	`{ "error": "analysis-unavailable" }`	Berechnung fehlgeschlagen oder Timeout. Erneut versuchen; in einem CI-Gate nicht als "keine Daten" werten.
`400`	`{ "error": "testrunname-and-testrunid-required" }`	Ein Parameter fehlt.

Das Dokument

{
  "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 ist die Zahl der aufgezeichneten Requests über alle Engines und Regionen. Jede andere Zahl wird aus diesen Samples berechnet, nicht aus Durchschnitten pro Engine.
overall ist der gesamte Lauf. Zeiten in Millisekunden; latency ist die Zeit bis zum ersten Byte, connect die Verbindungszeit. rps sind Samples geteilt durch die aktiven Sekunden des Laufs. first und last sind Epoch-Millisekunden.
labels enthält eine Zeile pro Request (URL oder Sampler-Name) mit denselben Feldern plus eigenen Perzentilen.
byThreads gruppiert Samples nach der Zahl der gerade aktiven virtuellen Nutzer. Lesen Sie es als Antwortzeit gegen Last: die Stufe, bei der mean oder max springt, ist Ihre Kapazität.
byRegion ist eine Zeile pro Cloud-Region bei Multi-Region-Läufen.
errorTypes ist eine Zeile pro Request und fehlgeschlagenem Statuscode mit der häufigsten Fehlermeldung und bis zu fünf topMessages.
perSecond ist die Fehlerrate über die Zeit; lange Läufe werden auf höchstens 3.600 Punkte reduziert.
histogram ist die Antwortzeitverteilung der Ergebnisseite, mit der Zahl der Samples oberhalb des letzten Buckets in over.
apdex nutzt ein Ziel von 500 ms: score ist (satisfied + tolerating / 2) / total.

Perzentile stammen aus 1.000 logarithmisch verteilten Buckets; p99 ist daher bis auf einen Bruchteil eines Prozents exakt und stimmt nicht millisekundengenau mit einer Tabellenkalkulation über die rohe JTL überein.

Eine Pipeline absichern

Für eine Bestanden/Nicht-bestanden-Entscheidung nutzen Sie stattdessen die Verdict-API: Sie wendet die am Test gespeicherten Schwellenwerte an und liefert ein Verdict, das auch die GitHub Action liest. Die Analyse-API brauchen Sie, wenn Sie die Zahlen selbst benötigen, etwa um p95 pro Endpunkt in einen Pull-Request-Kommentar zu schreiben oder eine eigene Trendhistorie zu führen.

Verwandt

Zurück

KI-Analyse von Lasttestergebnissen

Weiter

Seitengeschwindigkeit unter Last