Lasttest einer HTTP-Anfrage
Ein Knoten HTTP-Anfrage kann seine Anfrage viele Male senden, nach einem Profil von Anfragen pro Sekunde, viele gleichzeitig — und messen, was zurückkommt: Latenz-Perzentile, Fehler, die erreichte Rate. Schwellenwerte entscheiden, ob der Schritt besteht, und Vergleichen stellt die Zahlen neben die eines früheren Durchlaufs.
Last ist eine Einstellung des Knotens, kein eigener Knoten: Der Rest des Experiments — Emulatoren, Störungs-Relais, andere Zweige — läuft wie gewohnt um ihn herum.
Eine Anfrage unter Last setzen
- Wählen Sie einen Knoten HTTP-Anfrage aus und füllen Sie seine Anfrage aus.
- Haken Sie in seinen Eigenschaften unter Last senden an.
- Wählen Sie ein Profil und seine Zahlen. Das Diagramm darunter, Rate über die Zeit, zeichnet die Rate und sagt, wie viele Anfragen sich daraus ergeben, in wie vielen Sekunden.
- Setzen Sie Gleichzeitig — wie viele Anfragen gleichzeitig unterwegs sein dürfen.
- Fügen Sie Schwellenwerte hinzu oder ändern Sie sie.
- Führen Sie das Experiment aus.
Eine Last beginnt als Rampe von 0 auf 100 Anfragen pro Sekunde über 30.000 ms, 32 gleichzeitig, mit zwei Schwellenwerten: p95 < 500 ms und Fehler < 1 %.
Last ersetzt Wiederholung und Neuversuch. Wird sie eingeschaltet, werden beide ausgeschaltet, und ein Knoten mit Last und einem von beiden wird abgelehnt (node.load_alone): Eine fehlgeschlagene Anfrage wird gezählt, nicht erneut versucht. Nur eine HTTP-Anfrage kann unter Last laufen (node.load_unsupported).
Die Anfrage wird einmal gelesen. Ihre Vorlagen werden beim Start des Schritts aufgelöst, sodass jede Anfrage der Last dieselbe ist: {{counter}} und {{uuid}} haben für alle denselben Wert. Siehe Vorlagen.
Ein Client für die ganze Last. Die Anfragen teilen sich den Cookie-Speicher des Durchlaufs, wenn Cookies zwischen Anfragen behalten an ist, und ein Digest-Gedächtnis, sodass eine einzige Challenge sie alle beantwortet. Jede Anfrage hat das eigene Timeout des Knotens.
Der Inspektor erhält eine Stichprobe: höchstens einen Austausch alle 100 ms, damit eine Last den Inspektor nicht überflutet.
Profile
| Profil | Einstellungen | Die Rate über die Zeit |
|---|---|---|
| Konstant | Rate, Anfr./s, Dauer, ms | durchgehend die Rate |
| Rampe | Von, Anfr./s, Bis, Anfr./s, Dauer, ms | in gerader Linie von einer Rate zur anderen |
| Stufen | Von, Anfr./s, Stufe, Anfr./s, Je Stufe, ms, Stufen | zuerst die Anfangsrate, dann auf jeder Stufe um einen Schritt mehr, jede Stufe gleich lang |
| Spitze | Basis, Anfr./s, Spitze, Anfr./s, Spitze bei, ms, Spitzendauer, ms, Dauer, ms | die Grundrate, ab einem bestimmten Moment eine Weile die Spitze, dann wieder die Grundrate |
| Zufällig | Rate, Anfr./s, Dauer, ms | zufällige Ankünfte, die Rate im Mittel |
Beim Wechsel der Form bleibt erhalten, was sich übertragen lässt: wie lange sie läuft und die höchste Rate, die sie erreicht.
Grenzen
| Einstellung | Bereich |
|---|---|
| Rate, Anfr./s von Konstant und Zufällig, Spitze, Anfr./s | 0,1–100.000 Anfragen/s |
| Von, Anfr./s, Bis, Anfr./s, Basis, Anfr./s | 0–100.000 Anfragen/s |
| Jede Stufe von Stufen, die letzte eingeschlossen | 0–100.000 Anfragen/s; der Schritt darf negativ sein |
| Dauer, ms, Je Stufe, ms | 100–300.000 ms |
| Stufen | 1–100, und alle Stufen zusammen höchstens 300.000 ms |
| Eine Spitze | länger als 0 ms und bis zum Ende der Dauer vorbei |
| Gleichzeitig | 1–512 |
| Schwellenwerte | höchstens 16, jeder Wert eine Zahl, 0 oder größer |
Ein Profil, das insgesamt keine einzige Anfrage ergibt, wird abgelehnt (load.nothing_planned). Die Raten sind die des HTTP-Bursts.
Ein Profil darf so lange dauern wie ein ganzer Durchlauf, 300 s — doch das Zeitlimit des Durchlaufs zählt jeden Schritt, lassen Sie also Raum für den Rest des Experiments.
Wie viele Anfragen
Die Anfragen eines Profils sind seine Rate, über die Zeit aufsummiert:
| Profil | Anfragen |
|---|---|
| Konstant, 100/s für 1000 ms | 100 |
| Rampe, 0 → 100/s über 2000 ms | 100 |
| Stufen, ab 10/s in Schritten von 10/s, 3 Stufen zu je 1000 ms | 60 (10 + 20 + 30) |
| Spitze, 10/s mit 100/s ab 1000 ms für 500 ms, insgesamt 2000 ms | 65 |
| Zufällig, 200/s für 10.000 ms | im Mittel 2000 |
Der Zeitplan
Die n-te Anfrage ist in dem Moment fällig, in dem die Zählung des Profils n erreicht — die erste sofort. Jeder Moment wird ab dem Start der Last berechnet, sodass ein verspätetes Aufwachen nie die nachfolgenden Anfragen verschiebt und die Rate, die das Profil beschreibt, auch die angeforderte ist.
Das Profil Zufällig zieht die Abstände zwischen den Ankünften zufällig, aus dem Startwert des Durchlaufs: Derselbe Startwert ergibt dieselben Momente, sodass sich eine zufällige Last exakt wiederholen lässt. Siehe Startwerte.
Verpasste Anfragen. Höchstens so viele Anfragen, wie Gleichzeitig vorgibt, sind unterwegs. Wartet jede davon noch auf ihre Antwort, wartet die nächste Anfrage auf einen freien Platz. Würde sie mehr als 50 ms nach ihrem Moment hinausgehen, wird sie nicht verspätet gesendet: Sie wird übersprungen und als verpasst gezählt, mit jeder anderen Anfrage, die inzwischen fällig wurde, und die Last geht mit der ersten weiter, die noch pünktlich ist. Viele verpasste Anfragen bedeuten, dass der Server — oder der Wert Gleichzeitig — mit dem Profil nicht mithalten konnte.
Während sie läuft
Einmal pro Sekunde zeigt die Zeitleiste den Schritt als Unter Last, mit den vergangenen Sekunden, den gesendeten Anfragen, der Rate in der letzten Sekunde, dem bisherigen p95 und den fehlgeschlagenen Anfragen. Stoppen beendet die Last sofort und verwirft die Anfragen, die unterwegs sind; ein Fehler in einem anderen Zweig beendet sie innerhalb einer Sekunde.
Was gemessen wird
Nach der letzten Antwort hat der Schritt seine Messwerte, festgehalten in seinem letzten Ereignis der Zeitleiste und im Bericht des Durchlaufs:
| Messwert | Was |
|---|---|
| planned | die Anfragen, die das Profil ergibt (Zufällig: im Mittel) |
| sent | Anfragen, die beantwortet wurden oder fehlschlugen |
| ok | mit einem 2xx-Status beantwortet |
| failed | jeder andere Status oder gar keine Antwort |
| missed | fällig, während jeder Platz belegt war, und übersprungen |
| rps | gesendete Anfragen pro Sekunde: sent ÷ Dauer des Profils — oder ÷ die Zeit bis zur letzten gesendeten Anfrage, wenn das später war |
| error_rate | failed, in % von sent |
| min, mean, max | die schnellste, die durchschnittliche und die langsamste Anfrage, ms |
| p50, p90, p95, p99 | die Latenz, bei oder unter der 50, 90, 95 und 99 % der Anfragen lagen, ms |
| received_bytes | insgesamt empfangene Body-Bytes |
| statuses | Anfragen nach Status (200, 503) und, ohne Status, nach Ursache (timeout, refused, reset …) |
| seconds | jede Sekunde des Profils: gesendete Anfragen, fehlgeschlagene, ihre mittlere Latenz |
| histogram | Anfragen nach Latenz, bis 1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10.000 ms und langsamer |
Die Latenz einer Anfrage reicht vom Senden bis zum vollständigen Lesen ihrer Antwort, und eine fehlgeschlagene Anfrage zählt mit der Zeit, die sie bis zum Fehlschlag brauchte. Die Perzentile werden aus logarithmischen Klassen von 1 % Breite gelesen und liegen höchstens 0,5 % neben dem wahren Wert, wie lange die Last auch läuft.
Schwellenwerte
Ein Schwellenwert ist eine Zeile aus Metrik, Vergleich und Wert; die Schaltfläche Schwellenwert fügt einen hinzu.
| Metrik | Gemessen in |
|---|---|
| p50, p90, p95, p99 | ms |
| Mittelwert, Langsamste | ms |
| Fehler | % der gesendeten Anfragen |
| Rate | erreichte Anfragen pro Sekunde |
| Verpasst | Anfragen |
Vergleich ist einer von <, ≤, >, ≥. Ein paar gebräuchliche:
| Metrik | Vergleich | Wert | Der Schritt schlägt fehl, wenn |
|---|---|---|---|
| p95 | < | 300 | eine von zwanzig Anfragen oder mehr 300 ms oder länger dauerte |
| Fehler | < | 1 | 1 % oder mehr der Anfragen fehlschlugen |
| Rate | ≥ | 180 | der Server keine 180 Anfragen pro Sekunde annehmen konnte |
| Verpasst | ≤ | 0 | auch nur eine einzige Anfrage übersprungen werden musste |
In einer Datei ist ein Schwellenwert { "metric": "p95_ms", "op": "lt", "value": 300 }; die Metriken sind p50_ms, p90_ms, p95_ms, p99_ms, mean_ms, max_ms, error_rate, rps und missed, die Vergleiche lt, le, gt und ge.
Die Schwellenwerte werden nach der letzten Antwort gelesen, in ihrer Reihenfolge. Der Schritt schlägt beim ersten fehl, der nicht eingehalten ist (load.threshold); seine Meldung nennt den Schwellenwert und den gemessenen Wert, und der Durchlauf schlägt mit ihm fehl. Ohne Schwellenwerte besteht eine Last, was immer sie gemessen hat. Hat der Fehler eines anderen Zweigs die Last vorzeitig beendet, ist dieser Fehler der des Durchlaufs, nicht ein Schwellenwert.
Das Ergebnis
Besteht der Schritt, fasst die Zeitleiste ihn zusammen: die Anfragen, die Rate, p95 und den Anteil der fehlgeschlagenen. Wählen Sie den Knoten aus: Seine Eigenschaften zeigen Last des letzten Durchlaufs —
- jeden Schwellenwert, ✓ Eingehalten oder ✕ Nicht erfüllt, mit dem gemessenen Wert;
- Gesendet, Anfr./s, Fehler mit ihrem Anteil, Verpasst;
- p50, p90, p95, p99, Mittel, Max;
- Pro Sekunde: die Anfragen jeder Sekunde, die fehlgeschlagenen in Rot, und ihre mittlere Latenz als Linie;
- Latenzen: wie viele Anfragen wie lange gedauert haben;
- die Status und Ursachen, jeweils mit ihrer Anzahl.
Die Kommandozeile gibt dieselben Zahlen und das Urteil jedes Schwellenwerts aus; siehe signallab run.
Zwei Durchläufe vergleichen
- Führen Sie das Experiment zweimal oder öfter aus.
- Drücken Sie in der Zeitleiste Vergleichen. Die Schaltfläche ist da, sobald ein Durchlauf seinen Bericht gespeichert hat, und ist deaktiviert, solange ein Durchlauf läuft.
- Der neueste Durchlauf ist Nachher, der davor Vorher; in beiden Listen lässt sich ein anderer Durchlauf wählen.
Die Listen enthalten die Durchläufe dieses Experiments — nach seinem Namen — aus den Berichten im Datenordner, die neuesten zuerst, höchstens 50: jeder mit Datum und Uhrzeit, wie er endete, und seinem Startwert. Durchläufe von der Kommandozeile sind ebenfalls dabei, wenn sie denselben Datenordner verwendet hat. Wird das Experiment umbenannt, beginnt eine neue Historie.
Für jeden Lastschritt, nach Knoten zugeordnet, zeigt eine Tabelle jede Metrik in den Spalten Vorher, Nachher und Änderung, in der Einheit und in %. Eine Änderung um 5 % oder mehr in die falsche Richtung — langsamer, mehr Fehler, mehr verpasste Anfragen, eine niedrigere Rate — ist eine Verschlechterung und erscheint in Rot; der Schritt von nichts zu etwas zählt ebenfalls. Unter der Tabelle steht das Urteil jedes Schwellenwerts in beiden Durchläufen. Ein Lastschritt, den nur einer der Durchläufe hat, ist als nur vorher oder nur nachher markiert, ohne Änderungen. Durchläufe ohne Lastschritte zeigen Keine Lastschritte in diesen Durchläufen.
Aus einem Skript listet experiment_runs die Durchläufe auf, und experiment_compare vergleicht zwei, anhand des Dateinamens ihres Berichts; signallab mcp bietet dasselbe einem Assistenten an (MCP).
Prüfungen nach einer Last
Eine Last hinterlässt keine eigene Antwort: Sie wird gemessen, nicht geprüft. Eine Prüfung oder ein Knoten Wert extrahieren danach braucht auf jedem Pfad davor eine weitere Anfrage ohne Last, sonst läuft das Experiment nicht (graph.needs_http). Um eine Antwort der API unter Last zu prüfen, setzen Sie einen einfachen Knoten HTTP-Anfrage hinter die Last oder in einen parallelen Zweig daneben.
Jetzt senden an einem Knoten unter Last sendet seine Anfrage einmal.