Lasttests mit offenen und geschlossenen Workload-Modellen

Worum es geht

Ein Lasttest muss festlegen, wie neue Anfragen eintreffen. Bei einem geschlossenen Modell sendet jeder von einer festen Anzahl virtueller Benutzer eine Anfrage, wartet auf die Antwort und sendet dann die nächste; die k6-Dokumentation hält fest, dass im geschlossenen Modell eine neue Iteration erst startet, wenn die vorherige abgeschlossen ist, sodass die Ankunftsrate an die Antwortzeit gekoppelt ist. Bei einem offenen Modell treffen Anfragen mit einer konfigurierten Rate ein, unabhängig davon, ob frühere bereits abgeschlossen sind – so verhält sich anonymer Verkehr: Besucher warten nicht aufeinander. Die beiden Modelle wurden in Schroeder, Wierman und Harchol-Balters NSDI-2006-Papier «Open Versus Closed: A Cautionary Tale» gegenübergestellt, das analysiert, wie sich das Systemverhalten unter beiden Modellen unterscheidet.

Warum es wichtig ist

Unter einem geschlossenen Modell drosselt ein langsamer werdender Server seinen eigenen Lastgenerator: Es treffen weniger Anfragen pro Sekunde ein, und die langsamsten Phasen werden am wenigsten erfasst. Die k6-Dokumentation nennt das Coordinated Omission; das wrk2-README erklärt, dass ein Generator, der auf jede Antwort wartet, mit dem Server koordiniert und dadurch vermeidet, während Phasen hoher Latenz zu messen, und dass wrk2 die Latenz deshalb ab dem Zeitpunkt misst, zu dem eine Anfrage bei der konfigurierten konstanten Durchsatzrate hätte gesendet werden müssen. Ein geschlossener Test kann eine gesunde Tail-Latenz für einen Dienst melden, der bei der tatsächlichen Ankunftsrate zusammenbrechen würde.

So wird es angewendet

• Das Modell aus der Fragestellung ableiten. «Wie verhält sich der Dienst bei N Anfragen pro Sekunde?» braucht ein offenes Modell (k6 constant-arrival-rate, die Option --rate von wrk2). «Wie verhalten sich K Worker mit Denkzeit?» (Batch-Clients, ein fester Pool von API-Aufrufern) ist tatsächlich geschlossen.
• Bei Tests mit offenem Modell genügend virtuelle Benutzer vorab bereitstellen; kann das Werkzeug die Zielrate nicht halten, ist das selbst der Befund, und das Werkzeug sollte das ausweisen.
• Perzentile aus vollständigen Histogrammen angeben, nie Mittelwerte, und Ankunftsmodell, Rate, Rampenprofil und Dauer bei jeder Zahl nennen.
• In Stufen hochfahren und jede Stufe lange genug halten, damit sich Warteschlangen setzen, bevor Ergebnisse gelesen werden.
• Den Generator auf separater Hardware betreiben und prüfen, dass er nicht selbst der Engpass ist (CPU, kurzlebige Ports, Dateideskriptoren).

Stolpersteine

Zahlen aus den beiden Modellen sind nicht vergleichbar, ihre Vermischung in einem Bericht führt daher in die Irre. Werkzeuge mit geschlossenem Modell und Denkzeit null erzeugen eine Last Schlag auf Schlag, wie sie kein Client erzeugt. Tests mit offenem Modell gegen einen überlasteten Dienst lassen Warteschlangen unbegrenzt wachsen, bis dem Client die Ressourcen ausgehen; das ist das korrekte Ergebnis, kein Fehler im Werkzeug. Anfragen, die immer denselben zwischengespeicherten Schlüssel treffen, lassen einen Dienst schneller erscheinen, als er ist.