loadtest.app

Amdahlsches Gesetz: Formel, Beispiele und Grenzen

Sun, 01 Nov 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Das Amdahlsche Gesetz (Amdahl's Law) besagt, dass die Beschleunigung durch parallele Ausführung von dem Teil begrenzt wird, der sich nicht parallelisieren lässt. Verteilt sich ein Anteil p der Arbeit auf n Prozessoren, Server oder Threads, beträgt die Beschleunigung S = 1 / ((1 − p) + p/n), und wie groß n auch wird, sie übersteigt nie 1 / (1 − p). Bei 95 % paralleler Arbeit liegt die Obergrenze beim 20-Fachen, selbst auf tausend Maschinen.

Die Zahlen unten sind reine Arithmetik ohne Testlauf dahinter. Die zitierten Arbeiten wurden am 1. November 2026 geprüft.

Paralleler Anteil p	n = 2	n = 8	n = 64	n → ∞
0,50	1,33	1,78	1,97	2
0,90	1,82	4,71	8,77	10
0,95	1,90	5,93	15,42	20
0,99	1,98	7,48	39,26	100

Was besagt das Gesetz in einfachen Worten?

Ein Job kann nicht schneller fertig werden als sein serieller Teil, also verkürzen zusätzliche Worker nur den Rest. Ist der parallele Teil erst klein im Vergleich zum seriellen, ändern weitere Worker die Gesamtzeit kaum noch.

Nehmen Sie einen Job von 10 Sekunden, von denen 1 Sekunde seriell ist (ein Lock, ein einzelner Schreibvorgang) und sich 9 Sekunden gleichmäßig aufteilen, also p = 0,9. Acht Worker erledigen ihn in 1 + 9/8 = 2,125 Sekunden (4,71-mal schneller); vierundsechzig brauchen etwa 1,14 Sekunden. Unter 1 Sekunde kommt er nie, also ist 10 die Obergrenze.

Woher stammt das Gesetz?

Gene Amdahl trug das Argument 1967 auf der AFIPS Spring Joint Computer Conference vor, in einem Aufsatz, der den Ansatz mit einem einzelnen Prozessor verteidigte.

Den Volltext von Validity of the single processor approach to achieving large scale computing capabilities haben wir nicht gelesen. Mark Hill und Michael Marty fassen ihn in Amdahl's Law in the Multicore Era (IEEE Computer, 2008) zusammen: ein Anteil unbegrenzt parallelisierbar ohne Scheduling-Overhead, der Rest vollständig sequenziell, und die Beschleunigung beschrieben, ohne eine Gleichung anzugeben („without presenting an equation“).

Was bedeutet es für Last- und Kapazitätstests?

Der Durchsatz wächst nicht mehr im gleichen Maß mit Servern, Threads oder Pods, sobald eine gemeinsame Komponente einen Teil jeder Anfrage nacheinander abarbeitet. Ein Lasttest zeigt das als Durchsatzkurve, die abflacht, während Sie weiter Kapazität hinzufügen.

Neil Gunthers unten zitierter Aufsatz von 2008 schreibt dasselbe Gesetz als N / (1 + σ(N − 1)), mit σ als seriellem Anteil, und misst Skalierbarkeit als Durchsatz bei N geteilt durch den Durchsatz bei 1. In einem Websystem ist der serielle Teil alles, was jede Anfrage der Reihe nach passieren muss: ein Lock oder eine Zeile, die jede Anfrage aktualisiert, ein einzelner Datenbank-Primary, der alle Schreibvorgänge annimmt, ein einzelner Queue-Consumer oder eine Drittanbieter-API mit Rate-Limit.

Wie finden Sie den seriellen Teil in einem Lasttest?

Fahren Sie denselben Test auf mehreren Laststufen und beobachten Sie, welche Ressource in die Sättigung geht, während der Durchsatz abflacht. Die Komponente, die an ihrer Grenze ist, wenn zusätzliche Kapazität nichts mehr bringt, ist der serielle Teil oder die Warteschlange davor.

Typische Anzeichen: Der Durchsatz stagniert, obwohl die App-Schicht noch freie CPU hat, Wartezeiten wachsen an einer gemeinsamen Stelle (Locks, Datenbankverbindungen, Queue-Tiefe), und die Antwortzeit steigt im Gleichschritt mit den Benutzern, also Little's Law an einer Obergrenze. Ein Lauf mit konstanter Last kann das nicht zeigen, also steigern Sie die Last in Stufen. Die LoadFocus-Einstellung Ramp Up Steps fügt virtuelle Benutzer in gleich großen Gruppen hinzu. Die Kapazitätsanzeige gruppiert einen abgeschlossenen Lauf nach aktiven virtuellen Benutzern und listet in bezahlten Tarifen für Läufe mit nur einem Lastgenerator p95, Anfragen pro Sekunde und Fehlerrate pro Stufe. Eine Kapazitätsstufe nennt sie nur, wenn der Lauf mindestens drei Stufen durchlaufen hat und die oberste mindestens doppelt so hoch lag wie die unterste. Ein Skalierbarkeitsmodell passt sie nicht an, die Anpassung unten übernehmen also Sie.

Was ist Gustafsons Gesetz?

Es ist der Gegenpol: Wächst das Problem mit der Maschine, bleibt der serielle Anteil klein und die Beschleunigung wächst fast linear. Amdahl hält die Arbeit fest, Gustafson die Laufzeit.

John Gustafsons Notiz Reevaluating Amdahl's law von 1988 berichtete Beschleunigungen von 1016 bis 1021 auf einem Hypercube mit 1024 Prozessoren in Sandia, für Anwendungen mit einem seriellen Anteil von 0,4 bis 0,8 Prozent, und argumentierte, dass Benutzer das Problem so weit vergrößern, bis es die verfügbare Zeit ausfüllt. Mit s' als seriellem Anteil, gemessen am parallelen Lauf, ist die skalierte Beschleunigung N + (1 − N)s'; die Notiz schreibt diese Formel E. Barsis in Sandia zu.

Bei s' = 0,05 und 64 Prozessoren ergibt das 60,85 gegenüber 15,42 nach Amdahl, weil die beiden 5-%-Werte auf verschiedenen Maschinen gemessen werden. In einem Websystem passt Gustafson, wenn jeder zusätzliche Server mit seinem eigenen Teil der Daten arbeitet; Amdahl passt, wenn jeder zusätzliche Benutzer weiterhin dieselbe gemeinsame Zeile berührt.

Was ergänzt das Universal Scalability Law?

Einen zweiten Term für Kohärenz, also die Kosten, gemeinsame Daten zwischen Workern konsistent zu halten, die mit der Zahl der Worker-Paare wachsen. Damit kann der Durchsatz ein Maximum erreichen und danach sinken, während Sie Kapazität hinzufügen.

Gunthers A General Theory of Computational Scalability Based on Rational Functions (arXiv, 2008) formuliert das Universal Scalability Law (USL) so:

C(N) = N / (1 + σ(N - 1) + κN(N - 1))
peak at N* = sqrt((1 - σ) / κ)

σ steht für Contention (Serialisierung oder Warteschlangen) und κ für Kohärenz (inkonsistente Kopien von Daten); mit κ = 0 ergibt sich Amdahls Formel. Zu Gunthers Beispielen für den ungünstigsten Fall gehört das Aktualisieren von Datenbankeinträgen, und Durchsatz jenseits von N* nennt er „retrograde“, also rückläufig. Mit den Beispielwerten σ = 0,05 und κ = 0,001 liegt das Maximum bei etwa 31 Workern: Der relative Durchsatz beträgt 9,03 bei 32 und 7,82 bei 64, wo der σ-Term allein 15,42 vorhersagt.

Wie passen Sie das USL an eine Lasttestreihe an?

Messen Sie den Durchsatz auf mehreren Nebenläufigkeitsstufen, teilen Sie jeden Wert durch den Durchsatz bei einem Benutzer und bestimmen Sie σ und κ mit der Methode der kleinsten Quadrate.

Umgestellt lautet die Formel N / C − 1 = σ(N − 1) + κN(N − 1) und ist damit linear in σ und κ. Die Werte unten sind aus σ = 0,05 und κ = 0,001 erzeugt; tragen Sie Ihre eigenen Anfragen pro Sekunde pro Stufe in x ein:

import numpy as np

n = np.array([1, 2, 4, 8, 16, 32])          # virtual users
x = np.array([50, 95, 172, 284, 402, 452])  # req/s per level
c = x / x[0]                                # relative capacity
A = np.column_stack([n - 1, n * (n - 1)])
(s, k), *_ = np.linalg.lstsq(A, n / c - 1, rcond=None)
print(f"sigma={s:.3f} kappa={k:.4f}")
print(f"peak near {np.sqrt((1 - s) / k):.0f} users")

Das Skript gibt sigma=0.050, kappa=0.0010 und ein Maximum bei etwa 31 Benutzern aus. Ändern Sie zwischen den Stufen nur die Nebenläufigkeit und nehmen Sie eine Stufe mit einem Benutzer auf, denn jeder Punkt wird durch sie geteilt.

Wo sind diese Modelle nicht mehr nützlich?

Sie verdichten eine Durchsatzkurve auf ein oder zwei Konstanten, können also weder den schuldigen Lock benennen noch einem System folgen, das sich unter Last verändert. Nutzen Sie sie, um eine gemessene Kurve zu lesen und ein kurzes Stück fortzusetzen: Eine Anpassung auf Stufen weit unterhalb des Knicks sagt wenig über das Maximum.

Konstante Parameter. Ein Cache, der warm wird, ein Autoscaler oder ein Pool, der an seine Grenze stößt, verändert σ und κ mitten im Test.
Nur Durchsatz. p95 und p99 können sich zuerst verschlechtern: Prüfen Sie auch die Tail-Latenz.
Der Lastgenerator. Sättigt er zuerst, ist die flache Kurve seine eigene.
Geschlossene Tests. Feste virtuelle Benutzer messen ein geschlossenes System; echte Benutzer treffen in ihrem eigenen Tempo ein.

FAQ

Können Sie das Amdahlsche Gesetz einfach erklären? Ein Job ist nur so schnell wie der Teil, der sich nicht aufteilen lässt. Muss ein Zehntel der Arbeit seriell laufen, macht keine Zahl zusätzlicher Worker den Job mehr als zehnmal schneller, weil dieses Zehntel gleich lange dauert.

Was ist Gustafsons Gesetz? Gustafsons Gesetz besagt, dass die Beschleunigung fast linear wächst, wenn das Problem mit der Zahl der Prozessoren wächst, nämlich als N + (1 − N)s', mit s' als seriellem Anteil des parallelen Laufs. John Gustafson veröffentlichte es 1988 (die Formel schrieb er seinem Sandia-Kollegen E. Barsis zu) als Gegenpol zu Amdahls Annahme einer festen Problemgröße.

Weiterlesen

Warteschlangentheorie: was sie ist und warum Latenz steigt

Sun, 01 Nov 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Die Warteschlangentheorie (englisch queueing theory) ist die Mathematik der Warteschlangen: Aus der Rate, mit der Arbeit eintrifft, der Dauer jedes Auftrags und der Zahl der Server sagt sie voraus, wie lange Aufträge warten und wie lang die Schlange wird. Für Software ist ihr nützlichstes Ergebnis, dass die Antwortzeit bei mittlerer Last langsam und dann steil wächst, wenn ein Server sich 100 % Auslastung nähert. Im einfachsten Modell antwortet ein Server, der 90 % der Zeit beschäftigt ist, im Schnitt zehnmal langsamer als ein Server im Leerlauf.

Die Zahlen unten sind Arithmetik aus Standardformeln, mit einem Skript nachgerechnet, ohne Testlauf dahinter. Die Quellen wurden am 1. November 2026 geprüft.

Auslastung ρ	Zeit im System W ÷ Bedienzeit S	Bei S = 20 ms
0,5	2	40 ms
0,7	3,3	67 ms
0,8	5	100 ms
0,9	10	200 ms
0,95	20	400 ms
0,99	100	2.000 ms

Das sind Mittelwerte für die M/M/1-Warteschlange: ein Server, Poisson-Ankünfte und exponentialverteilte Bedienzeiten.

Was ist Warteschlangentheorie?

Sie ist das Teilgebiet der Wahrscheinlichkeitsrechnung, das Arbeit modelliert, die eintrifft, wartet und bedient wird. Eine Warteschlange wird durch ihre Ankünfte, ihre Bedienzeiten, ihre Zahl der Server und ihre Warteschlangendisziplin beschrieben, also die Reihenfolge, in der wartende Aufträge drankommen.

Larson und Odonis Urban Operations Research, ein frei zugänglicher MIT-Text, nennt Bankschalter, Supermarktkassen und Mautstellen als klassische Fälle. Ein Webserver passt in denselben Rahmen: Anfragen treffen ein, Threads oder Kerne bedienen sie, und der Rest wartet in einer Schlange.

Woher kommt die Warteschlangentheorie?

Aus der Telefonvermittlung, wo A. K. Erlang die ersten Ergebnisse für die Kopenhagener Telefongesellschaft erarbeitete.

Erlangs Aufsatz von 1909 zeigte, dass zufällig eingehende Anrufe der Poisson-Verteilung folgen, und seine Formel für Verluste und Wartezeiten von 1917 nutzten bald Telefongesellschaften in vielen Ländern, so die MacTutor-Biografie. David Kendalls Aufsatz von 1953, Stochastic Processes Occurring in the Theory of Queues and their Analysis by the Method of the Imbedded Markov Chain, führte die bis heute gebräuchliche Notation ein, wie Geoffrey Grimmetts Darstellung seines Werks festhält. Littles Beweis von L = λW und Kingmans Ergebnisse zu hoher Last folgten 1961.

Was bedeutet die Kendall-Notation wie M/M/1?

Sie benennt eine Warteschlange in drei Teilen, A/S/c: die Verteilung der Abstände zwischen Ankünften, die der Bedienzeiten und die Zahl der Server. M/M/1 heißt zufällige Ankünfte, exponentielle Bedienzeiten und ein Server.

M steht für memoryless, also gedächtnislos (Poisson-Ankünfte oder exponentielle Zeiten), D für deterministisch und G für general, also eine beliebige Verteilung: M/D/1 ist ein Server mit konstanter Bedienzeit.

Wie wächst die Antwortzeit mit der Auslastung?

In einer M/M/1-Warteschlange ist die mittlere Zeit im System W = 1/(μ − λ), also S/(1 − ρ). Nähert sich die Auslastung ρ dem Wert 1, wächst W unbegrenzt.

lambda = arrival rate        mu = service rate (1 / S)
rho    = lambda / mu         (utilization, must stay below 1)
W      = 1 / (mu - lambda)   = S / (1 - rho)

Larson und Odoni leiten das für eine Telefonzentrale mit einer Vermittlungskraft her und zeigen, dass es bei ρ ≥ 1 keinen stationären Zustand gibt: Die Schlange wächst immer weiter. Dieselbe Quelle zeigt, dass die Zeit im System exponentialverteilt ist. Jedes Perzentil wächst also mit demselben Faktor 1/(1 − ρ), und das p95 liegt bei etwa dem Dreifachen des Mittelwerts: 600 ms in der Zeile 0,9 oben.

Warum zeigt die Latenz einen Knick, bevor die CPU 100 % erreicht?

Weil eine Anfrage immer dann wartet, wenn sie den Server beschäftigt vorfindet, und das geschieht mit steigender Auslastung öfter. Unter M/M/1-Annahmen hat sich die Antwortzeit bei 50 % Auslastung schon verdoppelt.

Die Ressource, die sättigt, kann auch ein Connection-Pool, ein Datenbank-Lock oder eine Event-Loop mit nur einem Thread sein, und die am stärksten ausgelastete bestimmt die Kurve. Wegen des frühen Knicks liegt die Zielauslastung deutlich unter 100 %. Rechnen Sie vom Latenzbudget zurück: Mit S = 20 ms und einem Mittelwertziel von 100 ms erlaubt die Tabelle etwa 80 %, ein Ziel von 60 ms etwa 67 %, bevor Lastspitzen ihren Teil verlangen.

Die Kapazitätsanzeige von LoadFocus gruppiert einen abgeschlossenen Lauf nach der Zahl aktiver virtueller Benutzer und nennt die letzte Stufe, die hielt, bevor die Fehlerrate 1 % überschritt oder das p95 über das Doppelte der besten Stufe stieg, sofern sich keine höhere Stufe wieder erholte. Dafür braucht sie einen Lauf mit einem einzigen Lastgenerator, der mindestens drei Laststufen hochfährt, wobei die höchste mindestens doppelt so hoch ist wie die niedrigste. Nach der Rechnung oben greift die Verdopplung knapp oberhalb von 50 % Auslastung, wenn die leichteste Stufe den Engpass fast im Leerlauf ließ; hatte die leichteste Stufe ihn schon auf ρ0 ausgelastet, greift sie später, unter M/M/1 oberhalb von (1 + ρ0)/2.

Warum zählt Streuung so viel wie Auslastung?

Warteschlangen entstehen durch Zufall: Ankünfte in Schüben und gelegentlich langsame Aufträge. Unter hoher Last wächst die Wartezeit mit der Streuung beider, multipliziert mit einem Term ρ/(1 − ρ).

Kingmans Aufsatz von 1961, The single server queue in heavy traffic, zeigt, dass bei einer Verkehrsintensität eines einzelnen Servers nahe 1 die Schlange lang und die Wartezeit annähernd exponentialverteilt ist. Vorlesungsunterlagen der TU Eindhoven und des Technion geben eine Näherung für ihren Mittelwert an (das Technion nennt sie Allen-Cunneen-Näherung; weithin bekannt ist sie auch als Kingman-Formel):

Wq ≈ rho / (1 - rho) × (ca² + cs²) / 2 × S
ca, cs = coefficient of variation (std dev / mean)
         of arrival gaps and of service times

Wq ist die Wartezeit, bevor die Bedienung beginnt, und ca, cs sind die Variationskoeffizienten. Exponentielle Zeiten haben c² = 1, was die M/M/1-Wartezeit von 9S bei 90 % Auslastung ergibt. Eine konstante Bedienzeit halbiert sie auf 4,5S; cs² = 4, wie es eine Mischung aus Cache-Treffern und langsamen Datenbankaufrufen erzeugen kann, hebt sie auf 22,5S. Gleichmäßiger synthetischer Verkehr streut weniger als der Produktivbetrieb, also zeigt ein Test meist weniger Warteschlange, als echte Lastspitzen erzeugen.

Wie helfen mehr Server (M/M/c)?

Mehrere Server mit einer gemeinsamen Warteschlange fangen zufällige Schübe viel besser ab als dieselben Server mit je einer eigenen, sodass jeder Server bei gleicher Wartezeit stärker ausgelastet sein kann.

Nach Larson und Odonis M/M/m-Formeln beträgt W bei 90 % Auslastung jedes Servers 10S für einen Server, 5,3S für zwei mit gemeinsamer Schlange und 3,0S für vier. Vier Instanzen hinter einem Balancer, der eine freie wählt, verhalten sich wie der letzte Fall; vier, die jeweils ein zufälliges Viertel des Verkehrs bekommen, wie getrennte M/M/1-Warteschlangen mit 10S.

Wie passt Little's Law dazu?

Little's Law, L = λW, verknüpft die durchschnittliche Zahl der Anfragen in einem System mit ihrer Ankunftsrate und ihrer Verweilzeit, unabhängig von den Verteilungen. Die Warteschlangentheorie liefert W, und Little's Law macht daraus L.

In der Zeile 0,9 bedeuten 45 Anfragen pro Sekunde bei W = 200 ms im Schnitt 9 Anfragen im System. Unser Artikel zu Little's Law nutzt dasselbe Gesetz, um Lasttests zu dimensionieren und zu prüfen.

Wo versagen diese Modelle im Lasttest?

Sie setzen einen offenen Strom unabhängiger Ankünfte und einen stationären Zustand voraus. Ein Test mit fester Zahl virtueller Benutzer ist ein geschlossenes System, in dem die Ankünfte langsamer werden, sobald die Antworten es werden.

Geschlossene Tests. Bei N virtuellen Benutzern sind höchstens N Anfragen im System, also fällt die Anfragerate dort, wo eine offene Schlange wachsen würde, und Think Time senkt sie weiter. Unser Artikel zum offenen vs geschlossenen Lastmodell erklärt, warum das eine Sättigung verbirgt.
LoadFocus führt k6-Skripte aus, aber Arrival-Rate-Szenarien laufen dort mit einer festen Zahl von Benutzern, worauf der Skript-Validator hinweist. Lesen Sie solche Läufe als geschlossene Tests: Hinter dem Knick sind eine flache Anfragerate und steigende Antwortzeiten zu erwarten.
Stationärer Zustand. Aufwärmphase, Caches und Autoscaling ändern die Bedienrate während des Laufs, also vergleichen Sie Stufen, die lange genug gehalten wurden.

FAQ

Heißt es queueing theory oder queuing theory? Beide englischen Schreibweisen sind korrekt und bezeichnen dasselbe Gebiet. Kingmans Aufsatz von 1961 schreibt „queueing time“, während Littles Beweis aus demselben Jahr „Queuing Formula“ im Titel trägt.

Braucht die Warteschlangentheorie Poisson-Ankünfte? Nur für exakte M/M/1-Ergebnisse. G/G/1-Näherungen wie die Kingman-Formel arbeiten mit Mittelwert und Streuung der Ankunftsabstände und Bedienzeiten, und Little's Law braucht keine Annahme über die Verteilungen.

Weiterlesen

SLO vs. SLA: der Unterschied, SLIs und Fehlerbudgets

Sun, 01 Nov 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Ein SLA (Service Level Agreement) ist ein Vertrag mit einem Kunden, der festlegt, was passiert, wenn ein Dienst ein zugesagtes Niveau verfehlt, meist eine Gutschrift (Service Credit). Ein SLO (Service Level Objective) ist das interne Ziel, an dem ein Team den Dienst ausrichtet; das SRE-Buch rät, es strenger anzusetzen als das SLA, damit Probleme behoben sind, bevor der Vertrag verletzt wird. Ein SLI (Service Level Indicator) ist die Messgröße, in der beide formuliert sind, etwa der Anteil erfolgreicher Anfragen.

	SLI	SLO	SLA
Was es ist	Eine Messgröße	Ein Ziel für einen SLI	Ein Vertrag auf Basis von SLOs
Festgelegt von	Engineering	Product Owner und Engineering	Fachbereich und Rechtsabteilung
Bei Verfehlung	Für sich allein nichts	Fehlerbudget verbraucht	Gutschriften oder Vertragsstrafen
Beispiel	Erfolgreiche Checkout-Aufrufe	99,95 % über vier Wochen	99,9 % pro Monat, sonst Gutschrift

Die Beispiele dienen der Veranschaulichung; die Quellen sind Googles SRE-Buch und SRE-Workbook sowie das AWS-Compute-SLA, geprüft am 1. November 2026.

Wofür stehen SLI, SLO und SLA?

Service Level Indicator, Service Level Objective und Service Level Agreement. Der Indikator ist das, was Sie messen, das Ziel der Wert, den Sie anstreben, und die Vereinbarung das, was Sie jemand anderem zusagen, mit Konsequenzen.

Das Kapitel „Service Level Objectives“ im SRE-Buch definiert ein SLA als „ausdrücklichen oder stillschweigenden Vertrag mit Ihren Nutzern, der Konsequenzen für das Einhalten (oder Verfehlen) der darin enthaltenen SLOs vorsieht“. Der Test des Kapitels ist eine einzige Frage: Was passiert, wenn die SLOs verfehlt werden? Gibt es keine ausdrückliche Konsequenz, haben Sie es fast sicher mit einem SLO zu tun.

Das Kapitel ergänzt, dass die meisten Leute SLO meinen, wenn sie SLA sagen, und dass eine echte SLA-Verletzung als Vertragsbruch vor Gericht enden kann. Wenn eine Besprechung also in einen Streit über SLA vs. SLO kippt, fragen Sie zuerst, ob eine Konsequenz, meist Geld, in einem Vertrag festgeschrieben ist.

Das SRE-Buch rät zu einer Sicherheitsmarge: „Ein strengeres internes SLO als das den Nutzern kommunizierte SLO gibt Ihnen Raum, auf chronische Probleme zu reagieren, bevor sie nach außen sichtbar werden.“ Sein Kapitel „Embracing Risk“ wendet denselben Gedanken auf einen Vertrag an: ein externes Ziel von 99,9 %, abgesichert durch ein strengeres internes.

Was ist ein Fehlerbudget?

Es ist 100 % minus das SLO: der Anteil der Anfragen oder der Zeit, der im Zeitfenster fehlschlagen darf. Solange Budget übrig ist, liefert das Team weiter aus; ist es verbraucht, hat Zuverlässigkeitsarbeit Vorrang.

Das Kapitel „Implementing SLOs“ im SRE-Workbook rechnet es vor: Bei einem SLO von 99,9 % darf ein Dienst, der in vier Wochen 3 Millionen Anfragen erhält, bei 3.000 davon scheitern; ein einzelner Ausfall mit 1.500 Fehlern verbraucht also das halbe Budget. Das Kapitel „Embracing Risk“ des Buchs erklärt den Zweck: Das Produktmanagement legt das SLO fest, das Monitoring misst die tatsächliche Uptime, und die Differenz ist die Unzuverlässigkeit, die für das Quartal bleibt. Ist dieses Budget aufgebraucht, werden Releases gestoppt oder verlangsamt.

Wie viel Ausfallzeit erlaubt 99,9 %?

Etwa 43 Minuten in einem Zeitfenster von 30 Tagen. Jede weitere Neun teilt den Spielraum durch zehn, 99,99 % lassen also knapp über 4 Minuten.

SLO	Fehlerbudget	Ausfallzeit pro 30 Tage	Fehler pro Million
99 %	1 %	7 h 12 min	10.000
99,5 %	0,5 %	3 h 36 min	5.000
99,9 %	0,1 %	43 min 12 s	1.000
99,95 %	0,05 %	21 min 36 s	500
99,99 %	0,01 %	4 min 19 s	100

Multiplizieren Sie die 43.200 Minuten eines 30-Tage-Fensters mit dem Fehlerbudget. Beachten Sie die Warnung des Workbooks: Jede weitere Neun kostet mehr, während ihr Nutzen für die Anwender gegen null geht.

Wie sieht ein echtes SLA aus?

Es nennt einen gemessenen Prozentsatz, einen Abrechnungszeitraum, eine Staffel für Gutschriften und das, was nicht zählt. Das AWS-Compute-SLA ist ein kurzes öffentliches Beispiel.

Das Amazon Compute Service Level Agreement (zuletzt aktualisiert am 25. Mai 2022; geprüft am 1. November 2026) sagt eine Monthly Uptime Percentage von mindestens 99,99 % pro Region für EC2-Instanzen zu, die über zwei oder mehr Availability Zones verteilt sind, und 99,5 % für eine einzelne Instanz. Die Uptime ist 100 % minus der Anteil der Minuten, in denen EC2 nicht verfügbar war. Nach dem Region-Level SLA beträgt die Gutschrift unter 99,99 % 10 % der EC2-Monatsrechnung in der Region, unter 99,0 % 30 % und unter 95,0 % 100 %; bei einer einzelnen Instanz beginnt die 10-%-Stufe unter 99,5 %. Gutschriften werden mit künftigen Zahlungen verrechnet, müssen über den AWS Support beantragt werden und sind der „einzige und ausschließliche“ Rechtsbehelf, sofern die Kundenvereinbarung nichts anderes vorsieht.

Verglichen mit der Ausfalltabelle reicht die 10-%-Stufe des Region-Level SLA von etwa 4 Minuten bis 7 Stunden Nichtverfügbarkeit in einem 30-Tage-Monat. Ein SLA begrenzt, was der Anbieter schuldet; Ausfälle von Ihren Nutzern fernzuhalten, ist die Aufgabe Ihrer eigenen Ziele.

Wie wählt man SLIs für Latenz und Verfügbarkeit?

Messen Sie die Latenz als Perzentil und die Verfügbarkeit als gute Ereignisse geteilt durch alle Ereignisse, so nah am Nutzer wie möglich. Durchschnitte und reine Serverwerte verbergen die Anfragen, über die sich Leute beschweren.

Latenz. Das SRE-Buch zieht Perzentile dem Mittelwert vor, weil ein Durchschnitt flach bleiben kann, während die langsamsten Anfragen deutlich langsamer werden. Das Workbook schreibt Latenz-SLIs als Verhältnis, etwa Aufrufe unter 100 ms geteilt durch alle Aufrufe. „99 % der Checkout-Aufrufe unter 400 ms“ heißt also über das Zeitfenster dasselbe wie „p99 des Checkouts unter 400 ms“ und lässt sich direkt in einen Test übernehmen. Unser Artikel zur Tail-Latenz erklärt, warum p99 zählt, sobald eine Seite mehrere Dienste aufruft.

Verfügbarkeit. Zeitbasierte Verfügbarkeit zählt Minuten mit Uptime, wie das AWS-SLA. Anfragebasierte Verfügbarkeit zählt erfolgreiche Anfragen: „Embracing Risk“ beschreibt einen Dienst mit 2,5 Millionen Anfragen am Tag und einem Tagesziel von 99,99 %, der 250 Fehler liefern darf und das Ziel trotzdem erreicht.

Wo gehen SLOs schief?

Meist an zu vielen Zielen, an Zielen von 100 % und an Indikatoren, die dort messen, wo die Nutzer nicht sind. Jeder dieser Fehler ergibt eine Zahl, nach der niemand handelt, oder eine, die gut aussieht, während die Nutzer leiden.

Zu viele SLOs. Das SRE-Buch rät zu so wenigen wie möglich: Wenn sich mit einem SLO nie eine Diskussion über Prioritäten gewinnen lässt, lohnt es sich wahrscheinlich nicht.
Ziele von 100 %. Das Workbook nennt 100 % das falsche Ziel: Komponenten fallen aus, Änderungen sind die Hauptursache von Ausfällen, und ein SLO von 100 % lässt nur Zeit zum Reagieren.
Nur am Server messen. Servermetriken übersehen Probleme, die Nutzer spüren, etwa ein langsames Skript in der Seite. Das Workbook empfiehlt, am Load Balancer oder beim Client zu messen.

Was hat Lasttesten mit SLOs zu tun?

Ein SLO liefert einem Lasttest seine Pass/Fail-Kriterien, und ein Test bei der erwarteten Spitzenlast zeigt, ob das Latenz-SLO hält, bevor dieser Verkehr eintrifft. Das Monitoring in Produktion sagt es Ihnen erst hinterher.

Das SRE-Buch stellt fest, dass mehr Anfragen pro Sekunde (QPS) oft zu höheren Latenzen führen und Dienste jenseits einer bestimmten Lastschwelle häufig eine Leistungsklippe haben. Ein Lasttest kann diese Klippe finden, wenn er bei der erwarteten Spitzenlast mit einem realistischen Anfragemix läuft und denselben SLI misst, den das SLO nutzt. Setzen Sie jeden Schwellenwert im Test etwas strenger als das SLO, wie unser Leitfaden zu Pass/Fail-Kriterien für Lasttests beschreibt. Ein Lauf dauert Minuten und kann daher keine monatliche Verfügbarkeit messen.

LoadFocus, der Herausgeber dieser Website, bewertet Lasttests anhand von Pass/Fail-Schwellenwerten, die am Test gespeichert sind: Max P95 und Max P99 der Antwortzeit, eine maximale Fehlerrate und ein Mindestdurchsatz, für Cloud-, JMeter- und k6-Tests. Sein API-Monitoring bietet SLA-/SLO-Berichte, die pro Monitor ein SLO-Ziel festlegen und Uptime, verbrauchtes Fehlerbudget und einen Status OK oder Breached zeigen.

FAQ

Wofür steht SLO? Service Level Objective: ein Zielwert für ein gemessenes Serviceniveau, etwa 99,9 % erfolgreiche Anfragen über vier Wochen. Es wird intern festgelegt, von Produkt und Engineering, und zieht für sich allein keine vertragliche Strafe nach sich.

Kann man ein SLO ohne SLA haben? Ja. Das SRE-Buch nennt die Google-Suche als wichtigen Dienst ohne öffentliches SLA, der trotzdem mit SLIs und SLOs gesteuert wird.

Sollte ein SLO jemals 100 % betragen? Nein. Ein Ziel von 100 % lässt kein Fehlerbudget übrig, jeder Fehler verletzt es also, und keine Änderung lässt sich je gefahrlos ausliefern.

Weiterlesen

TPC-H: was der Benchmark misst und wie Sie ihn ausführen

Sun, 01 Nov 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

TPC-H ist der Benchmark für Entscheidungsunterstützung des Transaction Processing Performance Council (TPC): 22 geschäftliche Abfragen und zwei Refresh-Funktionen laufen gegen acht Tabellen, die das TPC-Programm dbgen bei einem gewählten Skalierungsfaktor füllt, wobei Faktor 1 etwa 1 GB entspricht. Seine Kennzahl QphH@Size kombiniert einen Power-Test (ein einzelner Abfragestrom) mit einem Durchsatztest (mehrere Abfrageströme), und offizielle Ergebnisse nennen zusätzlich einen Preis pro kQphH@Size. Nur auditierte, auf tpc.org veröffentlichte Ergebnisse gelten als offiziell; jede außerhalb von tpc.org veröffentlichte Zahl im Stil von TPC-H gilt nach den Fair-Use-Regeln des TPC als abgeleiteter Workload und darf nicht mit offiziellen Ergebnissen verglichen werden.

Wir haben den Benchmark für diesen Leitfaden nicht selbst ausgeführt. Die Fakten stammen von tpc.org, aus der Spezifikation in Revision 3.0.1, die tpc.org als aktuell führt, und aus der Dokumentation der jeweiligen Tools, alles geprüft am 1. November 2026. Die Einschätzungen sind unsere eigenen.

	TPC-H	TPC-C	TPC-DS
Workload	Entscheidungsunterstützung: Ad-hoc-Abfragen plus Datenaktualisierungen	OLTP: Bestellungen eines Großhändlers	Entscheidungsunterstützung: Abfragen plus Datenpflege
Umfang	8 Tabellen, 22 Abfragen, 2 Refresh-Funktionen	9 Tabellentypen, 5 Transaktionstypen	Snowflake-Schema, 7 Faktentabellen, 99 Abfragen
Primäre Kennzahl	QphH@Size und $/kQphH@Size	tpmC	QphDS@SF und $/kQphDS@SF
Aktuelle Version	3.0.1	5.11.0	4.0.0

Was misst TPC-H?

Wie schnell ein System komplexe analytische Abfragen über einen großen Datenbestand beantwortet, während neue Verkäufe eintreffen und alte gelöscht werden. Eine einzige Spezifikation legt Schema, Abfragen, Daten und Regeln fest.

Die TPC-H-Seite beschreibt eine Reihe geschäftsorientierter Ad-hoc-Abfragen mit gleichzeitigen Datenänderungen (geprüft am 1. November 2026). Die Spezifikation definiert acht Tabellen: PART, PARTSUPP, LINEITEM, ORDERS, CUSTOMER, SUPPLIER, NATION und REGION. Alle außer den letzten beiden wachsen mit dem Skalierungsfaktor; LINEITEM, die größte, enthält etwa 6.000.000 Zeilen pro Einheit. Die Refresh-Funktion RF1 fügt neue Zeilen in ORDERS und LINEITEM ein, RF2 entfernt alte Verkäufe (geprüft am 1. November 2026).

Wie wird das TPC-H-Ergebnis berechnet?

Ein Lauf besteht aus einem Power-Test und einem anschließenden Durchsatztest, und QphH@Size ist das geometrische Mittel beider Ergebnisse. Die Preiskennzahl ist der Gesamtpreis des Systems geteilt durch QphH@Size, mal 1.000.

Im Power-Test führt ein Refresh-Strom RF1 aus, eine einzelne Abfragesitzung führt alle 22 Abfragen einmal aus, dann führt der Refresh-Strom RF2 aus. Power@Size ist 3.600 mal der Skalierungsfaktor, geteilt durch das geometrische Mittel dieser 24 Zeiten. Im Durchsatztest laufen mehrere Abfrageströme neben einem Refresh-Strom: mindestens 2 bei Faktor 1, bis zu 11 bei Faktor 100.000. Throughput@Size sind die Abfragen pro Stunde über alle Ströme, mal den Skalierungsfaktor. Ein vollständiger Test hat zwei Läufe, und der Sponsor meldet den mit dem niedrigeren QphH (alles laut Spezifikation, geprüft am 1. November 2026).

Das geometrische Mittel gewichtet jede Abfrage gleich, daher hebt die Halbierung der Zeit einer einzigen Abfrage Power nur um etwa 3 %. Ein offizielles Ergebnis nutzt einen Skalierungsfaktor aus einer festen Liste: 1, 10, 30, 100 und so weiter bis 100.000.

Wer veröffentlicht TPC-H-Ergebnisse, und welche zählen?

Hersteller, die einen Test sponsern, veröffentlichen auditierte Ergebnisse auf tpc.org, und nur diese gelten als offiziell. Jeder andere Lauf ist ein abgeleiteter Workload mit eigenen Regeln.

Die Spezifikation verlangt ein unabhängiges Audit durch einen vom TPC zertifizierten Auditor. Die Fair-Use-Kurzreferenz des TPC erlaubt den TPC-Namen neben Ergebnissen nur für offiziell veröffentlichte Ergebnisse. Alles andere braucht das Präfix „Derived from“, darf die TPC-Kennzahl nicht verwenden, muss einen Hinweis tragen, dass es mit veröffentlichten Ergebnissen nicht vergleichbar ist, sollte Umgebung und Abweichungen offenlegen und darf nicht mit offiziellen Ergebnissen verglichen werden (geprüft am 1. November 2026).

Wie führen Sie TPC-H selbst aus?

Erzeugen Sie Daten und Abfragetext, laden Sie die Tabellen und führen Sie dann den Power-Test und anschließend den Durchsatztest aus. Dafür eignen sich die Tools des TPC, ein Kit für eine bestimmte Datenbank oder eine Engine mit eingebautem Generator.

Die Seite mit den aktuellen Spezifikationen des TPC bietet ein kostenloses Tool-Paket an: Sie registrieren sich, akzeptieren eine Lizenz und erhalten den Link per E-Mail. Laut Spezifikation müssen DBGen die Daten und QGen den Abfragetext erzeugen (geprüft am 1. November 2026).

Für PostgreSQL beschreibt die TPC-H-Seite im Wiki kein Schritt-für-Schritt-Verfahren und verweist auf DBT-3, ein vollständiges Kit, das die DBT-3-Seite des Wikis eine Fair-Use-Implementierung der Spezifikation nennt. HammerDB bringt TPROC-H mit, das seine Dokumentation als von TPC-H abgeleiteten Open-Source-Workload beschreibt, der mit veröffentlichten Ergebnissen nicht vergleichbar ist. Es läuft auf PostgreSQL, MySQL, Oracle und weiteren Engines, und die Dokumentation empfiehlt, das geometrische Mittel der Abfragezeiten zu vergleichen, statt QphH zu berechnen (alles geprüft am 1. November 2026).

DuckDB hat eine Extension tpch, die laut ihrer Dokumentation den Datengenerator und die Abfragen implementiert. Diese Zeilen erzeugen Faktor 1, führen Abfrage 4 aus und listen die 22 Abfragen auf:

CALL dbgen(sf = 1);
PRAGMA tpch(4);
FROM tpch_queries();

Dieselbe Seite warnt, dass die Daten leicht von der Spezifikation abweichen, dass jede Abfrage mit festen Parametern läuft und dass dbgen bestehende Tabellen nicht löscht. Für vollständig konforme Daten verweist sie auf tpchgen-cli (geprüft am 1. November 2026).

Wie lesen Sie TPC-H-Ergebnisse ehrlich?

Vergleichen Sie Ergebnisse nur bei gleichem Skalierungsfaktor und gleicher Benchmark-Version, und lesen Sie jede Kennzahl mit ihrem Größensuffix. Ein Diagramm einzelner Abfragezeiten zeigt weder den Power-Test noch den Durchsatztest.

Die Ergebnisseite gruppiert die Ergebnisse nach Datenbankgröße und enthält drei Hinweise: Ergebnisse der Versionen 2 und 3 sind nicht vergleichbar, Preis-Leistung in verschiedenen Währungen sollte nicht verglichen werden, und Vergleiche über Datenbankgrößen hinweg sind irreführend (geprüft am 1. November 2026). Die Spezifikation ergänzt, dass Ergebnisse mit unterschiedlicher Zahl von Strömen bei gleicher Datenbankgröße vergleichbar sind.

Achten Sie bei einem informellen Lauf auf das, was die Fair-Use-Regeln verlangen: Hardware und Arbeitsspeicher, Änderungen an Schema oder Abfragetext und ob Refresh-Funktionen liefen. Ein Beitrag, der die 22 Abfragen einmal mit warmem Cache und ohne Refresh-Strom misst, bildet nur die Abfragehälfte eines Power-Tests ab, wobei ein solcher Lauf für die eigene Regressionskontrolle trotzdem hilft. Zum Verhältnis von Abfragerate und Antwortzeit siehe Durchsatz vs. Latenz.

Wann sollten Sie etwas anderes als TPC-H nutzen?

Wenn der Workload transaktional ist, wenn Sie einen neueren Analytics-Benchmark möchten oder wenn es darum geht, was Benutzer erleben. Der Benchmark bildet einen analytischen Workload ab, ohne kurze Transaktionen und ohne Anwendungsschicht.

Wählen Sie TPC-DS für einen breiteren Test der Entscheidungsunterstützung: Die Spezifikation in Version 4.0.0 nutzt ein Snowflake-Schema mit sieben Faktentabellen und 99 Abfragen, und die Übersichtsseite sagt, dass Ergebnisse der Version 4 nicht mit früheren Versionen vergleichbar sind. Wählen Sie TPC-C oder das TPROC-C von HammerDB für OLTP im Stil einer Auftragserfassung: Die TPC-C-Seite beschreibt fünf Transaktionstypen, gemessen in tpmC (alles geprüft am 1. November 2026). Für einen schnellen Check einer einzelnen Datenbank deckt pgbench PostgreSQL ab und sysbench MySQL.

LoadFocus, der Herausgeber dieser Website, führt TPC-H nicht aus; seine Tests zielen auf Web- und API-Endpoints. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen aus, ohne JDBC-Treiber und ohne SQL-Modul, und kann sich daher nicht mit der Datenbank verbinden. Wählen Sie für diese Aufgabe statt LoadFocus ein Datenbank-Benchmark-Tool wie die DuckDB-Extension, DBT-3 oder HammerDB, und nutzen Sie LoadFocus für die Web- oder API-Schicht vor der Datenbank.

FAQ

Was ist der Unterschied zwischen TPC-H und TPC-DS? Beide sind Benchmarks des TPC für Entscheidungsunterstützung. TPC-H nutzt 8 Tabellen und 22 Abfragen und meldet QphH@Size, TPC-DS nutzt ein Snowflake-Schema mit sieben Faktentabellen und 99 Abfragen und meldet QphDS@SF.

Was bedeutet QphH@Size in TPC-H? Es ist die zusammengesetzte Kennzahl für Abfragen pro Stunde: das geometrische Mittel der Ergebnisse von Power-Test und Durchsatztest bei einer Datenbankgröße. Das Suffix nennt diese Größe, etwa QphH@1000GB, und Ergebnisse bei verschiedenen Größen sollten nicht verglichen werden.

Kann LoadFocus TPC-H ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte gegen Web- und API-Endpoints aus und hat keine SQL-Verbindung, nutzen Sie also für TPC-H ein Datenbank-Benchmark-Tool und LoadFocus für die Anwendungsschicht vor der Datenbank.

Weiterlesen

pgbench: PostgreSQL benchmarken und unter Last testen

Sat, 31 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

pgbench ist das Benchmark-Programm, das mit PostgreSQL ausgeliefert wird: Es führt dieselbe SQL-Transaktion in mehreren gleichzeitigen Datenbanksitzungen immer wieder aus und meldet Transaktionen pro Sekunde und Latenz. Die Testtabellen legen Sie mit pgbench -i -s 50 mydb an, danach startet etwa pgbench -c 10 -j 2 -T 300 mydb zehn Clients auf zwei Threads für fünf Minuten. Es misst nur die Datenbank und sagt daher nichts darüber, was Benutzer über die Anwendung davor erleben.

Wir haben pgbench für diesen Leitfaden nicht selbst ausgeführt. Die Fakten stammen aus der pgbench-Seite der Dokumentation zu PostgreSQL 18, der Version, die postgresql.org als aktuell führt, geprüft am 31. Oktober 2026; die Einschätzungen sind unsere eigenen.

Option	Wirkung
`-i` / `-s`	Testtabellen anlegen / Skalierungsfaktor (100.000 Konten pro Einheit)
`-c`	Clients, also gleichzeitige Datenbanksitzungen (Standard 1)
`-j`	Worker-Threads in pgbench (Standard 1)
`-T` / `-t`	Laufzeit in Sekunden oder Transaktionen pro Client (Standard 10)
`-b` / `-f`	Eingebautes Skript oder eigene Datei, optional mit `@Gewicht`
`-P`	Fortschrittsbericht alle N Sekunden
`-R` / `-L`	Zielrate in tps / Latenzgrenze in ms
`-r` / `-l`	Latenzen pro Anweisung / eine Logzeile pro Transaktion

Was misst pgbench?

Es führt ein Transaktionsskript in einer festen Zahl von Datenbanksitzungen immer wieder aus und meldet die durchschnittliche Transaktionsrate und die Latenz. Das Standardskript lehnt sich lose an den Banken-Benchmark TPC-B an.

Laut pgbench-Dokumentation ist das Standardszenario von TPC-B inspiriert und eben kein echtes TPC-B, daher der Name: Die Ausgabe nennt es TPC-B (sort of) (geprüft am 31. Oktober 2026).

Wie richten Sie eine pgbench-Datenbank ein?

Führen Sie pgbench -i gegen eine bestehende Datenbank aus, mit -s für den Skalierungsfaktor. Der Befehl legt vier Tabellen an und löscht vorhandene Tabellen gleichen Namens, geben Sie pgbench also eine eigene Datenbank.

Bei Faktor 1 enthält pgbench_branches eine Zeile, pgbench_tellers 10, pgbench_accounts 100.000 und pgbench_history keine, und -s vervielfacht diese Zeilen: -s 100 ergibt 10.000.000 Zeilen in pgbench_accounts. Eine Größe auf der Festplatte nennt die Dokumentation nicht, messen Sie sie also nach der Initialisierung (geprüft am 31. Oktober 2026).

Welche eingebauten Skripte bringt pgbench mit?

Drei: tpcb-like (der Standard), simple-update und select-only. Sie wählen eines mit -b oder mit den Kurzformen -N und -S.

Das Standardskript führt sieben Befehle pro Transaktion aus: BEGIN, ein Update und ein Select auf ein zufälliges Konto, Updates auf pgbench_tellers und pgbench_branches, einen Insert in pgbench_history und END. simple-update lässt die beiden Updates auf den kleinen Tabellen weg, vermeidet so Konflikte dort und entfernt den Test laut Dokumentation noch weiter von TPC-B. select-only sendet nur das Select.

Wie schreiben Sie ein eigenes pgbench-Skript?

Schreiben Sie Ihr SQL in eine Datei, setzen Sie Variablen mit \set und den Zufallsfunktionen und übergeben Sie die Datei mit -f. Jede Ausführung der Datei zählt als eine Transaktion.

\set aid random(1, 100000 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta
  WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
END;

Ein Gewicht nach @ legt fest, wie oft jedes Skript gewählt wird: -f update.sql@9 -b select-only@1 wählt die Datei in etwa neun von zehn Fällen. Die Dokumentation nennt außerdem random_exponential, random_gaussian und random_zipfian, mit denen sich einige Zeilen zu Hotspots machen lassen. \sleep fügt eine Pause ein, das Datenbank-Gegenstück zur Think Time. Wenn Sie nur eigene Dateien ausführen, geben Sie den Skalierungsfaktor der Datenbank mit -s an, sonst bleibt :scale bei 1 und das Skript oben trifft nur die ersten 100.000 Konten. Mit eigenen Tabellen lassen Sie -i weg und setzen -n, damit pgbench die Standardtabellen nicht per VACUUM bereinigt (geprüft am 31. Oktober 2026).

Welche Optionen machen pgbench zum Lasttest?

Die Parallelität kommt aus -c und -j, die Dauer aus -T und die Form der Last aus -R. Ohne -R startet jeder Client seine nächste Transaktion, sobald die vorige endet.

Diese Voreinstellung ist ein geschlossenes Lastmodell, wie unser Artikel zum offenen vs geschlossenen Lastmodell erklärt. Mit -R startet pgbench Transaktionen nach einem Poisson-verteilten Zeitplan, der ab dem Start des Clients voranschreitet, egal wie es früheren Transaktionen ergangen ist. Die gemeldete Latenz zählt dann ab dem geplanten Start und enthält so den Rückstand auf den Plan (Schedule Lag), dessen Mittelwert und Maximum getrennt erscheinen: genau die Korrektur, die unser Artikel zu Coordinated Omission beschreibt. Die Zahl der Clients bleibt fest; wächst der Rückstand immer weiter, schafft das System diese Rate mit den gewählten Clients und Threads nicht: Senken Sie -R oder erhöhen Sie die Zahl der Clients.

--latency-limit (-L) zählt Transaktionen, die länger als eine Grenze in Millisekunden dauern, als verspätet; mit -R überspringt pgbench außerdem Transaktionen, die schon zu weit hinter dem Plan liegen, und meldet sie als übersprungen. -M prepared nutzt Prepared Statements und läuft laut Dokumentation schneller als die anderen Modi (geprüft am 31. Oktober 2026).

Wie lesen Sie die Ausgabe von pgbench?

Die Zusammenfassung nennt die Einstellungen, verarbeitete und fehlgeschlagene Transaktionen, die mittlere Latenz, die anfängliche Verbindungszeit und tps. Die Form unten stammt aus der Dokumentation, ohne die Zahlen:

transaction type: <builtin: TPC-B (sort of)>
number of transactions actually processed: ...
number of failed transactions: ... (...%)
latency average = ... ms
latency stddev = ... ms   (only with -P, -R or -L)
initial connection time = ... ms
tps = ... (without initial connection time)

Fehlgeschlagene Transaktionen sind Serialisierungs- oder Deadlock-Fehler, die --max-tries wiederholen kann. Andere SQL-Fehler brechen den betroffenen Client ab und führen zum Exit-Status 2. Perzentile enthält die Zusammenfassung nicht: Für die Tail-Latenz protokollieren Sie jede Transaktion mit -l, das ihre Dauer in Mikrosekunden festhält, und berechnen p95 oder p99 selbst.

Ohne -P, -R oder -L wird die mittlere Latenz der Zusammenfassung nicht gemessen: pgbench leitet sie aus Laufzeit und Client-Zahl ab, also Little's Law rückwärts gerechnet, Fehlschläge eingeschlossen. Setzen Sie -P, wenn es auf die Latenz ankommt.

Wie bekommen Sie pgbench-Zahlen, denen Sie trauen können?

Lassen Sie jeden Lauf mehrere Minuten dauern, wiederholen Sie ihn, halten Sie den Skalierungsfaktor mindestens so groß wie die Zahl der Clients und behalten Sie VACUUM im Blick. Wird pgbench selbst zum Engpass, verlegen Sie es auf eine andere Maschine.

Die erste Richtlinie im Abschnitt „Good Practices“ der Dokumentation warnt davor, einem Test zu glauben, der nur wenige Sekunden läuft, und ergänzt, dass reproduzierbare Zahlen Stunden brauchen können (geprüft am 31. Oktober 2026). Mit dem Standardskript misst ein Skalierungsfaktor unter der Client-Zahl vor allem Update-Konflikte, weil pgbench_branches nur -s Zeilen hat und jede Transaktion eine davon ändert. Tote Zeilen und Autovacuum verschieben die Ergebnisse zwischen den Läufen. Bei vielen Sitzungen kann pgbench seinen eigenen Host auslasten: Führen Sie es auf einer separaten Maschine mit niedriger Netzwerklatenz aus oder verteilen Sie mehrere Instanzen auf mehrere Maschinen.

Wann ist pgbench das falsche Tool?

Wenn es um Benutzer, eine andere Datenbank oder einen standardisierten OLTP-Mix geht. pgbench misst PostgreSQL allein, ohne Ihren Connection-Pool, Ihr ORM, Ihren Cache und Ihre HTTP-Schicht.

Um zu sehen, was Benutzer erleben, setzen Sie die HTTP- oder API-Schicht davor unter Last. LoadFocus, der Herausgeber dieser Website, führt kein pgbench aus und kann sich nicht direkt mit PostgreSQL verbinden: LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen Web- und API-Endpoints aus.

Wählen Sie für MySQL sysbench: Sein Repository beschreibt ein skriptfähiges Benchmark-Tool mit mehreren Threads und OLTP-artigen Datenbanktests. Wählen Sie HammerDB für einen Mix im Stil von TPC-C: Die Dokumentation beschreibt TPROC-C, einen von TPC-C abgeleiteten Workload, den HammerDB auf PostgreSQL und anderen Datenbanken ausführt. Wählen Sie JMeter mit dem Sampler JDBC Request, um SQL und HTTP in einem Testplan auf Ihren eigenen Maschinen zu mischen (alles geprüft am 31. Oktober 2026).

FAQ

Was bewirkt die Option -s in pgbench? Sie setzt bei der Initialisierung den Skalierungsfaktor. Jede Einheit fügt pgbench_accounts 100.000 Zeilen hinzu, -s 100 erzeugt also 10.000.000 Zeilen. Halten Sie den Wert beim Standardskript mindestens so groß wie Ihre Client-Zahl.

Was ist der Unterschied zwischen -c und -j in pgbench? Die Option -c legt die Zahl der simulierten Clients fest, jeder davon eine gleichzeitige Datenbanksitzung. Die Option -j legt fest, wie viele Worker-Threads in pgbench sich diese Clients teilen.

Kann LoadFocus pgbench ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus und hat keine direkte Verbindung zu PostgreSQL, Sie setzen damit also die Web- oder API-Schicht vor der Datenbank unter Last.

Weiterlesen

redis-benchmark: richtig nutzen und die Zahlen lesen

Sat, 31 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

redis-benchmark ist das Benchmark-Werkzeug, das mit Redis ausgeliefert wird: Es öffnet eine Anzahl von Client-Verbindungen (standardmäßig 50), sendet eine feste Zahl von Befehlen (standardmäßig 100.000) und meldet für jeden Test Anfragen pro Sekunde und Latenz. Starten Sie redis-benchmark -q -n 100000 gegen einen laufenden Server, grenzen Sie mit -t auf die Befehle ein, die Sie interessieren, und lesen Sie das Ergebnis als Geschwindigkeit einer einzelnen Redis-Instanz unter synthetischen Befehlen. Ihre Anwendung bringt einen eigenen Netzwerkweg, eine eigene Client-Bibliothek und einen eigenen Befehlsmix mit; rechnen Sie also mit anderen Werten.

Wir haben es am 31. Oktober 2026 auf einem Apple-M1-Max-Laptop ausgeführt, Redis 7.2.6 als Server und Client auf derselben Maschine über Loopback, ohne Persistenz. Jede Zeile ist ein Lauf mit 100.000 Anfragen, die Anfragen pro Sekunde auf Tausend gerundet; p50 steht so da, wie das Tool es ausgab.

Lauf	Was sich ändert	Anfragen pro Sekunde	p50 (ms)
`-t set,get`	Nichts: 50 Clients, Werte mit 3 Byte	SET 113.000, GET 118.000	0,367; 0,351
`-t set,get -P 16`	16 Befehle pro Roundtrip	SET 1.010.000, GET 1.190.000	0,711; 0,583
`-t set,get -c 200`	200 Clients	SET 117.000, GET 123.000	1,135; 1,071
`-t set -d 1024`	Werte mit 1.024 Byte	SET 114.000	0,367
`-t set -r 100000`	Zufällige Schlüssel aus 100.000	SET 116.000	0,359
`script load "..."`	Ein eigener Befehl	106.000	0,415

Wie führen Sie redis-benchmark aus?

Richten Sie das Tool mit -h und -p auf einen laufenden Server; ohne Optionen läuft die Standard-Testreihe gegen 127.0.0.1:6379. Mit -t wählen Sie Tests aus, mit -q erhalten Sie eine Zeile pro Test.

redis-benchmark -h 10.0.0.12 -p 6379 -c 50 -n 100000 \
  -t set,get -q

Die offizielle Redis-Benchmark-Seite und die --help-Ausgabe von Version 7.2.6 nennen unter anderem diese Optionen (geprüft am 31. Oktober 2026):

-c parallele Verbindungen (Standard 50) und -n Anfragen insgesamt (Standard 100.000).
-d Größe der SET- und GET-Werte in Byte (Standard 3).
-P Befehle pro Pipeline (Standard 1, kein Pipelining).
-t eine kommagetrennte Liste von Tests; -q knappe Ausgabe; --csv CSV-Ausgabe.
-r zufällige Schlüssel aus einem Schlüsselraum dieser Größe. Ohne die Option nutzt jeder Befehl denselben Schlüssel.
-k 1 hält Verbindungen offen (Standard), -k 0 verbindet neu.
--threads schaltet den Multithread-Modus ein, --cluster den Cluster-Modus, in dem -c mindestens der Zahl der Knoten entsprechen muss.

Wie lesen Sie die Ausgabe von redis-benchmark?

Mit -q erhalten Sie pro Test eine Zeile: Anfragen pro Sekunde und die Median-Latenz. Ohne -q gibt jeder Test seine Einstellungen aus, eine Latenzverteilung nach Perzentilen und eine Zusammenfassung mit Durchschnitt, Minimum, p50, p95, p99 und Maximum.

Der Kopf zeigt außerdem die Server-Einstellungen save und appendonly, an denen Sie sehen, ob Persistenz Teil des Tests war. Unser vollständiger GET-Lauf ergab 119.617 Anfragen pro Sekunde, im Schnitt 0,352 ms, p95 0,559 ms, p99 0,623 ms und maximal 0,759 ms. Eine Anfrage, die Redis viele Male aufruft, trifft eher auf einen langsamen Aufruf, also lesen Sie auch p99; mehr dazu im Artikel über Tail-Latenz.

--csv gibt die Zusammenfassung als eine Zeile pro Test aus. Wiederholen Sie Läufe, bevor Sie einem kleinen Unterschied trauen: Zwei Läufe desselben SET-Tests ergaben bei uns etwa 113.000 und 125.000 Anfragen pro Sekunde.

Warum verändert Pipelining die Zahlen so stark?

Ohne -P wartet jeder Client auf eine Antwort, bevor er den nächsten Befehl sendet, sodass jeder Befehl einen vollen Roundtrip kostet. Mit -P 16 sendet jeder Client 16 auf einmal, und in unserem Lauf stieg SET von etwa 113.000 auf 1.010.000 Anfragen pro Sekunde, GET von 118.000 auf 1.190.000.

Die offizielle Seite nennt Pipelining realistisch, weil viele Redis-Anwendungen es nutzen, und rät zu einer Pipeline-Größe nahe dem Durchschnitt, den Ihre Anwendung tatsächlich erreicht. Unsere Median-Latenz stieg dabei auf 0,711 und 0,583 ms.

Was passiert, wenn Sie mehr Clients hinzufügen?

Ist der Engpass ausgelastet, bringen mehr Clients nur mehr Wartezeit. Auf einem einzelnen Laptop kann das der Server oder der Benchmark-Client mit nur einem Thread sein.

Von 50 auf 200 Clients blieb der Durchsatz fast gleich (etwa 117.000 SET- und 123.000 GET-Anfragen pro Sekunde), während sich die Median-Latenz ungefähr verdreifachte, auf 1,135 und 1,071 ms. Das ist Little's Law in Aktion. Jeder Client hat höchstens einen Befehl unterwegs, also legt -c fest, wie viele sich im System befinden, und wenn der Durchsatz nicht wachsen kann, muss die Zeit wachsen, die jeder dort verbringt. In unserem vollständigen GET-Lauf ergeben 50 Clients ÷ 119.617 Anfragen pro Sekunde 0,42 ms pro Client-Durchlauf, etwas mehr als der gemessene Durchschnitt von 0,352 ms. Mit 200 Clients ergibt dieselbe Rechnung 1,63 ms.

Damit folgt das Tool auch einem geschlossenen Lastmodell: Wenn Redis hängt, warten die Clients, und die Befehle, die Ihre Anwendung in der Zwischenzeit gesendet hätte, tauchen nie auf. Weder die offizielle Seite noch --help nennt eine Option für eine feste Anfragerate, lesen Sie die Perzentile also mit Blick auf Coordinated Omission.

Wie benchmarken Sie einen eigenen Befehl oder ein Lua-Skript?

Schreiben Sie den Befehl hinter die Optionen. Das Tool führt dann nur diesen Befehl aus und ignoriert -t.

redis-benchmark -n 100000 -q \
  script load "redis.call('set','foo','bar')"
redis-benchmark -r 10000 -n 10000 \
  eval 'return redis.call("ping")' 0

Die erste Zeile ist das Beispiel der offiziellen Seite; auf unserem Laptop lief es mit etwa 106.000 Anfragen pro Sekunde. SCRIPT LOAD lädt das Skript nur, also messen Sie mit eval wie in der zweiten Zeile aus --help, wie lange das Ausführen dauert. Mit -r wird laut Hilfe __rand_int__ in einem Argument durch eine zufällige zwölfstellige Zahl aus diesem Bereich ersetzt, und im Cluster-Modus muss der Schlüssel ein {tag} enthalten, damit der Befehl den richtigen Knoten erreicht.

Warum misst Ihre Anwendung andere Werte?

Ihre Anwendung misst ihren ganzen Weg zu Redis: Netzwerk, Client-Bibliothek, Serialisierung und ihren eigenen Befehlsmix. Die offizielle Seite nennt Fallstricke, die Sie vor einem Vergleich prüfen sollten.

Eine Schleife synchroner Befehle misst vor allem das Netzwerk und die Client-Bibliothek.
Laufen Client und Server auf einer Maschine, begrenzt die CPU den Benchmark. Unix Domain Sockets können auf manchen Plattformen, etwa Linux, rund 50 % mehr Durchsatz als TCP-Loopback erreichen.
Strings mit 4 KB bei 100.000 Anfragen pro Sekunde brauchen etwa 3,2 Gbit/s, mehr als eine 1-Gbit/s-Leitung trägt.
Für einen Vergleich mit einer transaktionalen Datenbank schalten Sie AOF ein und wählen eine passende fsync-Richtlinie.
Laptops ändern ihre CPU-Frequenz, was die Wiederholbarkeit verschlechtert.
INFO in regelmäßigen Abständen ist während eines Laufs wohl unproblematisch, MONITOR dagegen bremst Redis deutlich.

Zeigen diese Laptop-Zahlen die echte Kapazität von Redis?

Nein. Sie zeigen einen Laptop, der mit sich selbst spricht, ohne Netzwerk, meist mit Werten von 3 Byte, ohne Persistenz und mit einem Lauf pro Zeile.

Die Tabelle zeigt, wie jede Option die Werte verschiebt. Die Kapazität hängt von Ihrem Server, Ihrem Netzwerk, Ihren Wertgrößen und Ihren Persistenz-Einstellungen ab.

Wann ist redis-benchmark das falsche Werkzeug?

Wenn Sie wissen wollen, was Benutzer spüren. Es sendet synthetische Befehle nur an Redis, während die Antwortzeit einer Seite auch den Anwendungscode und dessen weitere Aufrufe enthält.

Dafür belasten Sie die Anwendung oder API, die Redis nutzt, und beobachten Redis währenddessen. LoadFocus, der Herausgeber dieser Website, arbeitet auf dieser Ebene und führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen Ihre Web-App oder API aus. LoadFocus führt redis-benchmark nicht aus.

Für mehr Kontrolle über den Redis-Traffic nennt das Repository von memtier_benchmark Multithread-Clients, ein Lese-Schreib-Verhältnis, zufällige oder sequenzielle Schlüsselmuster, Redis Cluster und TLS (geprüft am 31. Oktober 2026).

FAQ

Ist redis-benchmark dafür gebaut, Redis schnell aussehen zu lassen? Nein. Die offizielle Redis-Seite nennt das ein verbreitetes Missverständnis: Standardmäßig hat das Tool höchstens eine offene Anfrage pro Verbindung, ohne Pipelining, und ein Client mit Pipelining kann mehr Durchsatz erzeugen.

Wie füllen Sie eine Redis-Datenbank mit redis-benchmark? Führen Sie nur den SET-Test mit zufälligen Schlüsseln aus, wie die Hilfe des Tools zeigt: -t set -n 1000000 -r 100000000 füllt etwa eine Million Schlüssel. Zufällige Schlüssel können sich wiederholen, daher liegt die Endzahl etwas darunter.

Kann LoadFocus redis-benchmark ausführen? Nein. LoadFocus führt redis-benchmark nicht aus. Seine JMeter-Testpläne und k6-Skripte zielen auf die Web-App oder API vor Redis.

Weiterlesen

sysbench nutzen: CPU-, Festplatten- und MySQL-Benchmarks

Sat, 31 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

sysbench ist ein quelloffenes Multithread-Benchmark-Tool auf Basis von LuaJIT, das Tests für CPU, Arbeitsspeicher, Datei-I/O, Threads und Mutexe mitbringt, dazu OLTP-Skripte für MySQL und PostgreSQL. Tests mit Daten folgen demselben Ablauf: prepare legt Testdateien oder Tabellen an, run führt den Benchmark für eine feste Zeit oder Zahl von Events aus, und cleanup entfernt die Daten wieder; die CPU- und Speichertests brauchen nur run. Gemessen wird eine einzelne Maschine oder ein einzelner Datenbankserver; wie sich Ihre Anwendung unter echtem Benutzer-Traffic verhält, verrät sysbench daher nicht.

Wir haben sysbench für diesen Leitfaden nicht selbst ausgeführt. Die Fakten stammen aus der README und dem Quellcode im Master-Branch auf GitHub, geprüft am 31. Oktober 2026; die Ratschläge sind unsere eigenen.

Thema	sysbench
Lizenz	GPLv2
Geschrieben in	C, mit LuaJIT für Skripte
Letzte Version	1.0.20 (24. April 2020)
Letzter Commit	9. März 2025
Eingebaute Tests	`cpu`, `memory`, `fileio`, `threads`, `mutex`
Datenbankskripte	Acht `oltp_`-Skripte, `bulk_insert`, zwei `select_random_`
Datenbanktreiber	MySQL (Standard), PostgreSQL
Plattformen	Linux, macOS; Windows über WSL

Wird sysbench noch gepflegt?

Nur noch wenig. Die letzte Version, 1.0.20, erschien im April 2020; der Master-Branch hat seitdem gelegentlich Commits erhalten, von denen keiner in einer Version erschienen ist, zuletzt im März 2025.

Die Version 1.0.20 ist auf den 24. April 2020 datiert. Die Commit-Historie zeigt Änderungen wie einen gleichverteilten Standard für --rand-type (2020), ein Upstream-LuaJIT (2023) und Unterstützung für MariaDB-Client-Bibliotheken (2023), danach vier Build-Commits am 9. März 2025 (geprüft am 31. Oktober 2026). Die Paket-Repositorys aus der README werden bei jeder Version aktualisiert, für diese Änderungen brauchen Sie also einen Build aus dem Quellcode.

Wie läuft ein sysbench-Test ab?

Sie geben einen Test und einen Befehl an: sysbench [options] [testname] [command]. Der Test ist ein eingebauter Test, ein mitgeliefertes Lua-Skript oder Ihr eigenes Skript, der Befehl meist prepare, run, cleanup oder help.

Laut README legt prepare die Dateien für fileio an oder füllt die Datenbank für die OLTP-Skripte, cleanup entfernt diese Daten, und sysbench <testname> help listet die Optionen eines Tests auf. Ein Festplattentest:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

Der fileio-Quellcode nennt die Modi seqwr, seqrewr, seqrd, rndrd, rndwr und rndrw, standardmäßig mit insgesamt 2 GB an Dateien. Dateien, die in den Arbeitsspeicher passen, kann der Page Cache bedienen; wählen Sie die Gesamtgröße also größer als den RAM, wenn Sie die Festplatte messen wollen.

Wie messen Sie CPU und Arbeitsspeicher mit sysbench?

Mit sysbench cpu run und sysbench memory run. Der CPU-Test meldet Events pro Sekunde, wobei ein Event jede Zahl bis zu einer Grenze auf Primzahleigenschaft prüft; der Speichertest meldet Operationen und übertragene MiB pro Sekunde.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

Der CPU-Test setzt --cpu-max-prime standardmäßig auf 10000, und der Speichertest nimmt eine Blockgröße, eine Gesamtgröße, Lese- oder Schreiboperationen und sequenziellen oder zufälligen Zugriff entgegen (geprüft am 31. Oktober 2026). Vergleichen Sie nur Läufe mit identischen Einstellungen.

Wie testen Sie MySQL oder PostgreSQL mit sysbench?

Wählen Sie ein mitgeliefertes OLTP-Skript, füllen Sie die Tabellen mit prepare, führen Sie mit run Transaktionen aus mehreren Threads aus und löschen Sie die Tabellen danach mit cleanup. MySQL ist der Standardtreiber; PostgreSQL braucht --db-driver=pgsql und einen Build mit PostgreSQL-Unterstützung.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

Das gemeinsame OLTP-Skript legt eine Tabelle mit 10.000 Zeilen an, sofern Sie nicht --tables und --table-size angeben. In oltp_read_write führt jede Transaktion 10 Punktabfragen, vier Bereichsabfragen, zwei Updates und ein Delete mit anschließendem Insert zwischen BEGIN und COMMIT aus (geprüft am 31. Oktober 2026). Machen Sie die Daten größer als den Buffer Pool des Servers, wenn das Ergebnis Lesezugriffe auf die Festplatte enthalten soll.

Welche sysbench-Optionen sind am wichtigsten?

--threads und --time bestimmen Größe und Dauer eines Laufs, --rate setzt eine Ziel-Eventrate, und --report-interval, --percentile und --histogram entscheiden, was Sie zu sehen bekommen.

--threads: Worker-Threads, standardmäßig 1.
--time: Sekunden, standardmäßig 10, 0 für keine Grenze. --events begrenzt die Zahl der Events, und beide Grenzen gelten, kombinieren Sie es also mit --time=0.
--warmup-time: läuft zuerst ohne Statistik, damit kalte Caches das Ergebnis nicht verzerren. Nur im Master-Branch: Version 1.0.20 kennt die Option nicht.
--rate: durchschnittliche Events pro Sekunde über alle Threads; 0, der Standard, heißt so schnell wie möglich.
--report-interval: Werte pro Intervall alle N Sekunden, um Hänger sichtbar zu machen.
--percentile: das gemeldete Latenz-Perzentil, standardmäßig 95.
--histogram: ein Latenz-Histogramm am Ende, definiert in sb_logger.c.

Nutzt sysbench ein geschlossenes oder ein offenes Lastmodell?

Standardmäßig ein geschlossenes: Eine feste Zahl von Threads startet jeweils das nächste Event, sobald das vorige endet, ein langsamer Server bekommt also weniger Events. Mit --rate kommen die Events nach eigenem Zeitplan an, was einem offenen Lastmodell näherkommt.

Unser Artikel zum offenen vs geschlossenen Lastmodell erklärt, warum das verändert, was ein Benchmark misst. Im Standardmodus verzögert ein Hänger außerdem die Events, die währenddessen gestartet wären, und diese Verzögerungen tauchen in den Latenzwerten nie auf: Coordinated Omission. Die Hauptquelldatei zeigt, dass --rate Events in exponentialverteilten Abständen in eine Warteschlange stellt, die Wartezeit jedes Events zu seiner Latenz addiert und mit dem Fehler "event queue is full" abbricht, wenn die Threads nicht mithalten (geprüft am 31. Oktober 2026).

Wie lesen Sie die Ausgabe von sysbench?

Beginnen Sie mit dem Durchsatz: Events pro Sekunde, bei den OLTP-Skripten Transaktionen und Abfragen pro Sekunde. Lesen Sie dann den Latenzblock in Millisekunden: Minimum, Durchschnitt, Maximum, das gewählte Perzentil (standardmäßig p95) und die Summe.

Version 1.0.20 gibt statt „Throughput“ einen Block „General statistics“ mit der Gesamtzeit und der Gesamtzahl der Events aus. Die Feldnamen stammen aus dem Code für den Datenbankbericht und der Hauptquelldatei im Master-Branch, hier ohne Werte:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Ein 95. Perzentil blendet das langsamste von je zwanzig Events aus. Setzen Sie --percentile=99 oder ergänzen Sie --histogram, wenn es auf die Ausreißer ankommt; unser Leitfaden zur Tail-Latenz erklärt, warum.

Wann ist sysbench das falsche Tool?

Wenn sich Ihre Frage um Ihre Anwendung dreht. Ein CPU-Wert zeigt, wie schnell eine Maschine Primzahlen prüft, und ein OLTP-Lauf misst den Datenbankserver mit den Tabellen und Abfragen von sysbench, ohne Ihr Schema, Ihren Connection Pool oder den Netzwerkweg.

Wählen Sie pgbench für Tests, die ganz bei PostgreSQL bleiben: Die PostgreSQL-Dokumentation beschreibt ein Standardszenario, das lose auf TPC-B basiert, dazu eigene Skriptdateien (geprüft am 31. Oktober 2026).
Wählen Sie HammerDB für Tests im Stil von TPC-C: Die Dokumentation behandelt den von TPC-C abgeleiteten Workload TPROC-C für SQL Server, Db2, Oracle, PostgreSQL, MariaDB und MySQL (geprüft am 31. Oktober 2026).
Wählen Sie JMeter mit seinem Sampler JDBC Request, um SQL und HTTP in einem Testplan zu mischen; laut Anleitung für Datenbank-Testpläne gehört die .jar-Datei des Treibers in den lib-Ordner von JMeter.

LoadFocus, der Herausgeber dieser Website, führt kein sysbench aus und kann sich selbst nicht mit MySQL oder PostgreSQL verbinden. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen die Web- oder API-Schicht vor der Datenbank aus. Sinnvoll kombiniert: erst ein sysbench-Lauf, um den Datenbankserver zu dimensionieren, dann ein Lasttest der Anwendung, um zu sehen, ob echte Anfragen diese Grenze erreichen.

FAQ

Wird sysbench noch gepflegt? Nur wenig. Die letzte Version ist 1.0.20 vom 24. April 2020. Der Master-Branch hat seitdem gelegentlich Commits erhalten, keiner davon in einer Version, zuletzt am 9. März 2025.

Was bedeutet das 95. Perzentil in der Ausgabe von sysbench? Es ist die Latenz in Millisekunden, innerhalb derer 95 % der Events fertig wurden. 95 ist der Standardwert der Option --percentile, und Sie können einen anderen Wert wie 99 setzen.

Kann sysbench PostgreSQL testen? Ja. Die mitgelieferten OLTP-Skripte laufen mit --db-driver=pgsql gegen PostgreSQL, wenn sysbench mit PostgreSQL-Unterstützung gebaut wurde.

Kann LoadFocus sysbench ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte gegen Websites und APIs aus 25 Cloud-Regionen aus und verbindet sich nicht direkt mit MySQL oder PostgreSQL.

Weiterlesen

YCSB: Workloads A-F, Ausführung und Grenzen

Sat, 31 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

YCSB, der Yahoo! Cloud Serving Benchmark, ist ein Open-Source-Tool in Java, das synthetische Datensätze in einen Datenspeicher lädt und darauf dann eine feste Mischung aus Lese-, Update-, Insert- und Scan-Operationen ausführt, während es Durchsatz und Latenz pro Operation aufzeichnet. Seine sechs Core Workloads, A bis F, sind standardisierte Mischungen, sodass derselbe Test über Bindings gegen Cassandra, MongoDB, Redis, HBase und Dutzende weitere Datenbanken laufen kann. Es misst nur den Datenspeicher selbst und sagt daher nichts über die echten Abfragen Ihrer Anwendung oder über die Latenz, die Ihre Benutzer sehen.

Wir haben YCSB für diesen Artikel nicht selbst ausgeführt. Die Fakten stammen aus dem GitHub-Repository, dem Wiki und dem Quellcode, geprüft am 31. Oktober 2026; die Einschätzungen sind unsere eigenen.

Workload	Operationsmix	Schlüsselverteilung	Beispiel aus dem Wiki
A: updatelastig	50 % Lesen, 50 % Update	zipfian	Sitzungsspeicher, der letzte Aktionen festhält
B: überwiegend Lesen	95 % Lesen, 5 % Update	zipfian	Fotos taggen
C: nur Lesen	100 % Lesen	zipfian	Cache für Benutzerprofile
D: neueste lesen	95 % Lesen, 5 % Insert	latest	Statusmeldungen von Benutzern
E: kurze Bereiche	95 % Scan, 5 % Insert	zipfian (Scans über bis zu 100 Datensätze)	Diskussionsverläufe
F: Read-Modify-Write	50 % Lesen, 50 % Read-Modify-Write	zipfian	Benutzerdatenbank

Die Mischungen stammen aus den Dateien im Verzeichnis workloads, die Beispiele von der Seite Core Workloads (geprüft am 31. Oktober 2026). Jede Datei bringt nur 1.000 Datensätze und 1.000 Operationen mit: genug, um ein Setup zu debuggen, und viel zu wenig für einen Benchmark.

Was ist YCSB, und wird es noch gepflegt?

Es ist ein Workload-Generator mit einer Reihe standardisierter Workloads, um Key-Value- und "Cloud Serving"-Datenbanken zu vergleichen, 2010 von Yahoo! unter der Apache-2.0-Lizenz als Open Source veröffentlicht. Die letzte Version stammt vom Oktober 2019, der Code erhält aber weiterhin kleine Commits.

Die Seite mit Papers nennt das ursprüngliche Paper, "Benchmarking Cloud Serving Systems with YCSB" von Cooper, Silberstein, Tam, Ramakrishnan und Sears (ACM SoCC 2010). Das Release 0.17.0 ist auf den 6. Oktober 2019 datiert, und es gibt keinen neueren Tag; die Commit-Historie zeigt dagegen Arbeit aus 2026, etwa eine Option, nach einem fehlgeschlagenen Insert weiterzulaufen, und eine Änderung am Cloud-Spanner-Binding vom 20. Oktober (geprüft am 31. Oktober 2026). Diese Änderungen gibt es nur in einem eigenen Build aus dem Quellcode, und der braucht Maven 3.

Wie führen Sie einen YCSB-Benchmark aus?

In zwei Phasen mit denselben Properties: load fügt recordcount Datensätze ein, danach führt run operationcount Operationen aus dem Mix des Workloads aus. Sie nennen das Binding für Ihre Datenbank und übergeben die Workload-Datei mit -P.

bin/ycsb load mongodb -s -P workloads/workloada \
  -p recordcount=1000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb
bin/ycsb run mongodb -s -P workloads/workloada \
  -p recordcount=1000000 -p operationcount=5000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb \
  -threads 32 -target 20000

Die Seite Running a Workload erklärt die Details, über die viele stolpern (geprüft am 31. Oktober 2026). Der Client legt keine Tabellen an, Sie bilden usertable also vorher auf das ab, was Ihr Datenspeicher braucht, etwa eine Tabelle in MySQL oder einen Keyspace in Cassandra. Spätere -P-Dateien überschreiben frühere, und -p überschreibt alle. Die Laufphase braucht denselben recordcount wie die Ladephase, weil sie die Schlüssel aus dem gesamten Datenbestand wählt. -s gibt alle 10 Sekunden eine Statuszeile aus. Weil D und E Datensätze einfügen, empfiehlt die Seite Core Workloads, einmal mit der Datei von Workload A zu laden, A, B, C, F und D auszuführen, dann die Daten zu löschen und für E neu zu laden.

Was steuern -threads und -target?

-threads legt fest, wie viele Client-Threads Operationen senden (standardmäßig einer), und -target begrenzt die Operationen pro Sekunde insgesamt. Ohne Target sendet jeder Thread seine nächste Operation, sobald die vorige zurückkommt, eine langsamere Datenbank bekommt also einfach weniger Last.

Das ist ein geschlossenes Lastmodell, und unser Artikel zum offenen vs geschlossenen Lastmodell erklärt, was dieses Modell verdeckt. Das Wiki-Beispiel mit 10 Threads und einem Target von 100 Operationen pro Sekunde geht nur auf, solange die mittlere Latenz unter 100 ms bleibt; mit zu wenigen Threads bleibt die erreichte Rate unter dem Target. Hier wirkt Little's Law: Threads geteilt durch die mittlere Latenz begrenzen den Durchsatz. Wenn Sie mehrere Targets fahren und jeweils die Latenz notieren, erhalten Sie die Kurve aus unserem Leitfaden zu Durchsatz vs. Latenz.

Wie lesen Sie die Ausgabe von YCSB?

Am Ende jeder Phase gibt der Client einen [OVERALL]-Block mit Laufzeit und Durchsatz aus, dann einen Block pro Operationstyp mit Anzahl, mittlerer, minimaler und maximaler Latenz, Perzentilen und einer Zählung pro Rückgabecode.

Diese Feldnamen stammen aus dem Quellcode von 0.17.0; die Werte sind Platzhalter:

[OVERALL], RunTime(ms), <total>
[OVERALL], Throughput(ops/sec), <rate>
[READ], Operations, <count>
[READ], AverageLatency(us), <value>
[READ], 95thPercentileLatency(us), <value>
[READ], 99thPercentileLatency(us), <value>
[READ], Return=OK, <count>

Die Beispielausgabe im Wiki zeigt Millisekunden, die standardmäßige HdrHistogram-Messung meldet aber sowohl in 0.17.0 als auch im aktuellen Quellcode Mikrosekunden, (us). Die Seite Core Properties und Version 0.17.0 setzen die Standard-Perzentile auf 95 und 99, änderbar mit hdrhistogram.percentiles; seit April 2025 ergänzt der Master-Branch 50, ein Build aus dem Quellcode gibt also auch 50thPercentileLatency(us) aus (geprüft am 31. Oktober 2026). Die README lenkt den Blick auf P99 und darüber hinaus, warnt, dass sich Perzentile nicht mitteln lassen, und rät, bei mehreren Clients HDR-Histogramm-Dateien mit hdrhistogram.fileoutput=true zu speichern und zusammenzuführen.

Berücksichtigt YCSB Coordinated Omission?

Nur wenn Sie es verlangen, und nur mit gesetztem -target. Standardmäßig wird jede Latenz ab dem Moment gemessen, in dem die Operation tatsächlich gesendet wurde, sodass ein Stillstand, der die nachfolgenden Operationen verzögert, kaum sichtbar wird.

Der Mess-Quellcode kennt eine Property measurement.interval mit den Werten op (Standard), intended oder both (geprüft am 31. Oktober 2026). Mit Target merkt sich jeder Thread den geplanten Start jeder Operation; intended misst die Latenz ab diesem Zeitpunkt, und both fügt neben den üblichen Blöcken Intended--Blöcke wie [Intended-READ] hinzu. Im Wiki fehlt die Property, prüfen Sie also den Quellcode der Version, die Sie bauen. Unser Leitfaden zu Coordinated Omission erklärt, warum der geplante Start die ehrliche Zahl liefert.

Welche Datenbanken kann YCSB testen?

Jede, für die es ein Binding gibt. Die Build-Datei im Master-Branch listet 46 Binding-Module, darunter Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB und ein generisches JDBC-Binding.

Die Liste steht in der pom.xml, und jedes Binding-Verzeichnis hat eine eigene README mit den Verbindungs-Properties, etwa mongodb.url für das MongoDB-Binding (geprüft am 31. Oktober 2026). Laut der Seite Running a Workload reicht ein Client-Rechner für Cluster mit etwa 10 Maschinen; darüber starten Sie mehrere Clients, und die Seite Running a Workload in Parallel teilt die Last mit insertstart und insertcount zwischen ihnen auf.

Wann ist YCSB das falsche Tool?

Wenn Ihre Frage Ihre Anwendung betrifft. Der Core Workload schreibt synthetische Datensätze, standardmäßig 10 Felder mit je einer Länge von 100, über einfache Schlüsseloperationen und kann daher nicht zeigen, wie sich Ihre eigenen Abfragen, Indizes oder Ihr API-Code unter Last verhalten.

Für relationales OLTP führt pgbench ein an TPC-B angelehntes Skript gegen PostgreSQL aus und nimmt auch eigene Skripte an, und sysbench bringt OLTP-artige Lua-Benchmarks mit (beide geprüft am 31. Oktober 2026).
Für die Latenz, die Benutzer sehen, setzen Sie die HTTP- oder API-Schicht vor dem Datenspeicher unter Last. LoadFocus, der Herausgeber dieser Website, führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen Web- und API-Endpoints aus. LoadFocus führt kein YCSB aus.

FAQ

Was sind die Core Workloads von YCSB? Sechs standardisierte Mischungen: A besteht zu 50 % aus Lese- und zu 50 % aus Update-Operationen, B zu 95 % aus Lesen, C nur aus Lesen, D bevorzugt die zuletzt eingefügten Datensätze, E führt kurze Scans aus, und F macht Read-Modify-Write.

Was ist der Unterschied zwischen ycsb load und ycsb run? Die Ladephase fügt so viele Datensätze ein, wie recordcount angibt. Die Laufphase führt dann operationcount Operationen aus dem Mix des Workloads auf diesen Datensätzen aus und meldet Durchsatz und Latenz.

Wird YCSB noch gepflegt? Die letzte Version, 0.17.0, erschien am 6. Oktober 2019. Das Repository erhält weiterhin gelegentlich Commits, zuletzt am 20. Oktober 2026, neuere Korrekturen erfordern also einen Build aus dem Quellcode.

Kann LoadFocus YCSB-Benchmarks ausführen? Nein. LoadFocus führt kein YCSB aus. Seine JMeter-Testpläne und k6-Skripte zielen auf Web- und API-Endpoints, also auf die Schicht vor dem Datenspeicher.

Weiterlesen

NBomber-Lasttests: das .NET-Framework im Überblick

Wed, 21 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

NBomber ist ein Lasttest-Framework für .NET: Sie schreiben jeden Test als C#- oder F#-Szenario, fügen ihn einem gewöhnlichen Projekt hinzu und starten ihn wie jedes andere Programm. Ein NBomber-Lasttest passt zu Teams, die ohnehin in .NET entwickeln und ihre Lasttests in derselben Sprache, im selben Repository und mit demselben Test-Runner haben wollen. Kostenlos ist NBomber nur für private und akademische Nutzung; ein Unternehmen braucht eine bezahlte Lizenz, und diese eine Tatsache gibt bei mehr Evaluierungen den Ausschlag als jede Funktion.

Wir haben NBomber für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation, der Preisseite, dem GitHub-Repository und dem NuGet-Paket von NBomber, geprüft am 21. Oktober 2026; die Einschätzungen sind unsere eigenen.

Thema	NBomber
Lizenz	Kostenlos für private und akademische Nutzung; kostenpflichtig für Organisationen
Preis für ein Unternehmen	Business 1.500 $ pro Jahr, Enterprise 2.500 $ pro Jahr
Aktuelle Version	6.7.1 (16. Oktober 2026)
Laufzeit	.NET Standard 2.1, also .NET Core 3.0 oder neuer
Tests geschrieben als	C#- oder F#-Szenarien
Lastmodell	Inject (Ankunftsrate) oder konstante Kopien
Pass/Fail-Prüfungen	Schwellenwerte während des Laufs, Asserts auf die Endstatistik
Skalierung	NBomber Cluster, Enterprise-Lizenz

Wer entwickelt NBomber, und ist es kostenlos?

NBomber LLC entwickelt es, der Quellcode liegt auf GitHub. Kostenlos ist es für private, Hobby- und akademische Nutzung, und die Lizenzseite sagt klar, dass NBomber für Organisationen nicht kostenlos ist.

Die Lizenzseite zählt Benchmarks, Tutorials und Review-Inhalte zur privaten Nutzung. Im Unternehmen brauchen Sie eine Business- oder Enterprise-Lizenz, die pro Organisation vergeben wird statt pro Entwicklerplatz und keine Grenze für Instanzen oder parallele Läufe hat. Die Preisseite nennt für Business 1.500 $ pro Jahr und für Enterprise 2.500 $ pro Jahr, beide mit 30 Tagen Geld-zurück-Garantie. Der Lizenzschlüssel geht mit .WithLicense(...) oder einem Argument --license an den Runner, und NBomber braucht Internetzugang, um ihn zu prüfen; eine Offline-Prüfung gibt es auf Anfrage per E-Mail (geprüft am 21. Oktober 2026).

Die aktuelle Version ist v6.7.1, veröffentlicht am 16. Oktober 2026, vier Tage nach 6.7.0 (geprüft am 21. Oktober 2026).

Wie funktioniert ein NBomber-Szenario?

Ein Szenario ist ein Name plus eine asynchrone Funktion, deren Ausführung NBomber bei jedem Aufruf misst. Sie hängen Lastsimulationen und Schwellenwerte daran, registrieren es beim NBomberRunner und starten das Programm.

Dieser Test überspringt das Warm-up, steigert die Ankunftsrate über zwei Minuten auf 50 neue Szenario-Kopien pro Sekunde, hält sie zehn Minuten und endet mit Exit-Code 1, wenn 1 % oder mehr der Anfragen gescheitert sind. Für die Anfrage nutzt er das Plugin NBomber.Http:

var http = Http.CreateDefaultClient();

var scenario = Scenario.Create("browse", async context =>
{
    var request = Http.CreateRequest("GET",
        "https://staging.example.com/products");
    return await Http.Send(http, request);
})
.WithoutWarmUp()
.WithLoadSimulations(
    Simulation.RampingInject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(2)),
    Simulation.Inject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(10)))
.WithThresholds(
    Threshold.Create(s => s.Fail.Request.Percent < 1));

var result = NBomberRunner
    .RegisterScenarios(scenario).Run();
return result.Thresholds.Any(t => t.IsFailed) ? 1 : 0;

Die Seite zum HTTP-Client empfiehlt Http.CreateDefaultClient() statt eines einfachen new HttpClient() und sagt, dass das Plugin Statuscodes und übertragene Daten erfasst (geprüft am 21. Oktober 2026). Ein Schwellenwert allein vermerkt den Fehlschlag nur im Bericht; erst die letzte Zeile macht daraus einen Exit-Code, den eine Pipeline auswerten kann. Ohne .WithoutWarmUp() führt NBomber zuerst ein 30-sekündiges Warm-up mit den Simulationen des Szenarios aus, so die Seite zu Szenarien (geprüft am 21. Oktober 2026). Weil das Szenario gewöhnliches C# ist, lässt sich alles, was eine .NET-Bibliothek aufrufen kann, auf dieselbe Weise unter Last setzen.

Welche Lastmodelle bietet NBomber?

Beide Arten. Die Inject-Simulationen starten neue Kopien mit fester Rate, egal was frühere Kopien gerade tun, also ein offenes Lastmodell; die Constant-Simulationen halten eine feste Zahl von Kopien am Laufen, also ein geschlossenes.

Die Seite zur Lastsimulation führt sie auf (geprüft am 21. Oktober 2026):

Offen: Inject, RampingInject, InjectRandom und IterationsForInject.
Geschlossen: KeepConstant, RampingConstant und IterationsForConstant.
Zeitsteuerung: Pause, das den Start eines Szenarios verzögert oder es für eine feste Zeit pausiert.

Unser Artikel zum offenen vs geschlossenen Lastmodell erklärt, welches zu Ihrem Traffic passt. Eine öffentliche Website verhält sich meist wie das offene Modell, ein fester Pool interner Clients eher wie das geschlossene.

Wie funktionieren Schwellenwerte und Pass/Fail-Prüfungen?

Schwellenwerte zur Laufzeit prüfen die laufende Statistik, standardmäßig alle 5 Sekunden, und erscheinen im HTML-Bericht. Asserts, geschrieben in xUnit oder NUnit, prüfen die Endstatistik nach dem Lauf, und ein fehlgeschlagener Assert markiert den Lauf als fehlgeschlagen.

Die Seite zu Schwellenwerten zeigt Prüfungen auf Fehleranteil, Statuscodes, Perzentile der Latenz (p50, p75, p95, p99 und Maximum), Anfragen pro Sekunde und übertragene Bytes. Ein Schwellenwert stoppt den Test standardmäßig nicht; mit abortWhenErrorCount stoppt er nach einer festgelegten Zahl fehlgeschlagener Prüfungen (geprüft am 21. Oktober 2026). Einen Exit-Code nennt die Seite nicht; deshalb gibt das Beispiel oben selbst einen aus dem Ergebnis zurück. Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests zeigt, welche Grenzen sinnvoll sind.

Welche Protokolle kann NBomber testen?

Jedes Protokoll, das eine .NET-Bibliothek sprechen kann, denn NBomber misst nur den Code, den Sie ihm geben. Fertige Plugins gibt es für HTTP, WebSockets, MQTT und AMQP, dazu eine WebBrowser-Option.

Die Übersichtsseite beschreibt das Framework als unabhängig vom Protokoll, und die Preisseite führt diese Plugins in jedem Plan auf, auch im kostenlosen. Das gilt ebenso für Datenbanken und Message Queues, die Sie über ihre eigenen .NET-Clients ansprechen (geprüft am 21. Oktober 2026). Der Preis dafür: Außerhalb der Plugins schreiben und pflegen Sie den Client-Code selbst.

Wie skalieren Sie einen NBomber-Test?

Mit NBomber Cluster: Ein Coordinator steuert den Lauf, Agents führen die Szenarien aus, und alle kommunizieren über einen NATS-Message-Broker. Cluster gehört zur Enterprise-Lizenz.

Die Cluster-Übersicht erklärt die Rollen, und laut Lizenzseite können Entwickler ihn vor dem Kauf lokal mit einem Local Dev Cluster ausprobieren; die Seite zum Local Dev Cluster begrenzt ihn auf 1 Coordinator und 2 Agents und stoppt jeden Lauf nach einer Minute (geprüft am 21. Oktober 2026). Die Kubernetes-Integration von NBomber Studio, ebenfalls nur in Enterprise, richtet NATS und die Agent-Pods für Sie ein. Ohne Cluster läuft ein NBomber-Prozess auf einer Maschine; die Seite zu den Systemanforderungen empfiehlt für hohe Last 4 bis 8 CPU-Kerne.

LoadFocus, der Herausgeber dieser Website, führt keine NBomber-Tests aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen aus.

Was kann NBomber gut, und wo liegen seine Grenzen?

Stark ist es für .NET-Teams: Tests sind C#- oder F#-Code, jeder .NET-Client wird zum Lasttest, und beide Lastmodelle sind eingebaut. Seine Grenzen sind die Firmenlizenz, ein Ökosystem mit nur einer Sprache und kostenpflichtige verteilte Läufe.

Tests liegen neben dem Anwendungscode, mit derselben IDE, denselben Paketen und denselben Reviews.
Schwellenwerte sind eingebaut, und Asserts laufen in den xUnit- oder NUnit-Tests, die Sie schon haben.
Kommerzielle Nutzung braucht eine Lizenz, auch für einen einzelnen Entwickler.
Verteilte Läufe brauchen Enterprise und einen NATS-Broker.
Tester ohne .NET-Kenntnisse müssen erst C# oder F# lernen.

Wann sollten Sie stattdessen k6, Gatling oder JMeter wählen?

Wählen Sie ein anderes Tool, wenn Ihr Team nicht in .NET schreibt oder die Lizenzkosten nicht passen.

Wählen Sie k6, wenn Sie JavaScript-Skripte und ein Open-Source-Tool ohne Lizenzgebühr für den Firmeneinsatz wollen: Sein Repository steht unter AGPL-3.0 (geprüft am 21. Oktober 2026). LoadFocus führt k6-Skripte aus 25 Cloud-Regionen aus, Arrival-Rate-Szenarien allerdings mit fester Benutzerzahl. Wählen Sie Gatling für ein Code-first-Tool auf der JVM; unser Gatling-Review behandelt es. Wählen Sie JMeter, wenn Tester eine GUI bevorzugen oder Sie JDBC-, JMS- oder LDAP-Sampler von Haus aus brauchen. Der Überblick über Open-Source-Lasttest-Tools stellt sie nebeneinander.

FAQ

Ist NBomber für kommerzielle Nutzung kostenlos? Nein. NBomber ist nur für private und akademische Nutzung kostenlos. Ein Unternehmen braucht eine Business-Lizenz für 1.500 $ pro Jahr oder eine Enterprise-Lizenz für 2.500 $ pro Jahr.

Welche .NET-Versionen unterstützt NBomber? Es basiert auf .NET Standard 2.1 und läuft daher auf .NET Core 3.0 und jeder neueren .NET-Version. Die Dokumentation empfiehlt .NET 10.

Kann LoadFocus NBomber-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um NBomber auf mehr als einer Maschine laufen zu lassen, nutzen Sie NBomber Cluster, das eine Enterprise-Lizenz voraussetzt.

Weiterlesen

Tsung-Lasttests: das Erlang-Tool im Überblick

Wed, 21 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Tsung ist ein in Erlang geschriebenes Open-Source-Lasttest-Tool, das jeden Test in einer XML-Datei beschreibt und die Last auf viele Client-Maschinen verteilen kann. Ein Tsung-Lasttest ist weiterhin sinnvoll für Protokolle, die wenige Tools abdecken, etwa XMPP, LDAP oder PostgreSQL auf Protokollebene, und für sehr viele Benutzer auf bescheidener Hardware. Die letzte Version erschien im März 2023; für neue HTTP- oder API-Tests sind die meisten Teams daher mit k6, Gatling oder JMeter besser bedient.

Wir haben Tsung für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation und dem GitHub-Repository von Tsung, geprüft am 21. Oktober 2026; die Einschätzungen sind unsere eigenen.

Thema	Tsung
Lizenz	GPL-2.0
Geschrieben in	Erlang (braucht Erlang/OTP R16B03 oder neuer)
Letzte Version	1.8.0 (2. März 2023)
Tests geschrieben als	XML-Konfigurationsdateien
Lastmodell	Neue Benutzer pro Ankunftsphase (offen)
Protokolle	HTTP, WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, reines TCP/UDP (teils experimentell)
Skalierung	Client-Maschinen über SSH ohne Passwort
Berichte	Live-Dashboard auf Port 8091, HTML-Bericht mit `tsung_stats.pl`

Wer pflegt Tsung, und ist es noch aktiv?

ProcessOne hostet das Projekt unter GPL-2.0 auf GitHub. Es wird gepflegt, ist aber ruhig geworden: Die letzte Version, 1.8.0, stammt vom März 2023, und seither kommen nur gelegentlich zusammengeführte Pull Requests hinzu.

Das Repository zeigt den letzten Commit am 2. März 2026, einen Pull Request, der veraltete Aufrufe ersetzt, und der Tag v1.8.0 ist auf den 2. März 2023 datiert (geprüft am 21. Oktober 2026). Die Dokumentation trägt noch den Titel 1.7.0; prüfen Sie also das Repository, wenn ein Detail veraltet wirkt. Ein ruhiges Projekt bedeutet allerdings weniger Antworten, wenn etwas schiefgeht.

Wie funktioniert ein Tsung-Test?

Ein Test ist eine XML-Datei mit vier Hauptteilen: Client-Maschinen, Zielserver, Lastphasen und Benutzersitzungen. Jeder neue Benutzer wählt eine Sitzung nach ihrer Wahrscheinlichkeit und führt deren Anfragen der Reihe nach aus.

Dieser Ausschnitt startet zehn Minuten lang fünf neue Benutzer pro Sekunde; jeder lädt eine Produktliste, pausiert etwa zwei Sekunden und sendet dann eine POST-Anfrage an den Warenkorb:

<load>
  <arrivalphase phase="1" duration="10" unit="minute">
    <users arrivalrate="5" unit="second"/>
  </arrivalphase>
</load>
<sessions>
  <session name="browse" probability="100"
           type="ts_http">
    <request><http url="/products" method="GET"/></request>
    <thinktime value="2" random="true"/>
    <request><http url="/cart" method="POST"
                   contents="sku=A-100"/></request>
  </session>
</sessions>

Die Seite zu Sitzungen sagt, dass sich die Wahrscheinlichkeiten der Sitzungen zu 100 addieren müssen (seit 1.5.0 gehen auch Gewichte) und dass eine zufällige Think Time einer Exponentialverteilung um ihren Wert folgt, sofern Sie keinen Bereich mit min und max angeben (geprüft am 21. Oktober 2026). Für HTTP und PostgreSQL gibt es einen Proxy-Recorder, der eine Browser- oder Client-Sitzung in dieses XML übersetzt.

Welches Lastmodell nutzt Tsung?

Ein offenes Lastmodell. Jede Ankunftsphase startet neue Benutzer in festem Abstand oder mit fester Rate, egal was die bereits laufenden Benutzer tun, und eine Phase endet, wenn ihre Zeit abgelaufen ist, auch wenn ihre Sitzungen noch nicht fertig sind.

Die Seite zur Last nennt die Stellschrauben: interarrival oder arrivalrate pro Phase, maxnumber als Obergrenze für die Benutzer, die eine Phase startet, ein duration-Attribut für die gesamte Last, um den Test zu einer festen Zeit zu beenden, und wait_all_sessions_end, damit die nächste Phase wartet, bis die aktuellen Benutzer fertig sind (geprüft am 21. Oktober 2026). Unsere Artikel zum offenen vs geschlossenen Lastmodell und zur Think Time erklären, wie diese Entscheidungen verändern, was ein Test misst.

Welche Protokolle kann Tsung testen?

Mehr als die meisten Lasttest-Tools: HTTP (einschließlich SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT sowie reines TCP, UDP oder SSL. Die Dokumentation kennzeichnet die Plugins für MySQL, WebSocket, AMQP und MQTT als experimentell, AMQP nur in 0.9.1 und MQTT nur in 3.1.

Die Seite zu den Funktionen beschreibt jedes Plugin (geprüft am 21. Oktober 2026). Bei XMPP und PostgreSQL hatte Tsung lange wenige Konkurrenten: Es spricht das Protokoll selbst, Sie testen also den Server und nicht eine Client-Bibliothek. Für Echtzeit-Apps stellt unser Überblick über WebSocket-Lasttest-Tools Tsung neben neuere Optionen.

Wie verteilen Sie einen Tsung-Test auf mehrere Maschinen?

Sie listen die Client-Maschinen im XML auf, und der Controller startet die Last auf ihnen über SSH ohne Passwort oder über rsh. Jeder Client kann ein Gewicht, eine Benutzergrenze und eine CPU-Zahl erhalten.

Die Seite zu Clients und Server erklärt, dass Tsung auf jedem Client eine virtuelle Erlang-Maschine pro mit cpu angegebener CPU betreibt (standardmäßig eine) und eine neue startet, wenn eine VM maxusers erreicht. Client-Maschinen kann es auch von einem Batch-Scheduler wie PBS, LSF oder OAR übernehmen. Die Installationsseite nennt Erlang/OTP R16B03 oder neuer, dazu optional Perl 5 und gnuplot oder Python und matplotlib für die Grafiken (geprüft am 21. Oktober 2026).

LoadFocus, der Herausgeber dieser Website, führt keine Tsung-Dateien aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen aus.

Wie lesen Sie Tsung-Ergebnisse?

Auf zwei Wegen: über ein Live-Dashboard, das der Controller auf Port 8091 bereitstellt, und über einen HTML-Bericht, den das Skript tsung_stats.pl nach dem Lauf erzeugt.

Laut Seite zu den Berichten gibt es das Dashboard seit 1.6.0; es zeigt den aktuellen Status, erstellt Grafiken während des Tests und stoppt mit dem Testende, außer Sie starten Tsung mit -k (geprüft am 21. Oktober 2026). Der Bericht umfasst Antwort- und Verbindungsaufbauzeiten, Transaktionen, Anfragen pro Sekunde und Fehlercodes und kann CPU-, Speicher- und Netzwerkwerte der Server enthalten, gesammelt über Erlang-Agenten, SNMP oder munin. Einen Pass/Fail-Schwellenwert beschreibt die Dokumentation nicht, eine CI-Pipeline muss die Ergebnisse also selbst auswerten; unser Leitfaden zu Pass/Fail-Kriterien für Lasttests zeigt, was zu prüfen ist.

Was kann Tsung gut, und wo liegen seine Grenzen?

Stark ist es bei der Protokollbreite, bei offenen Ankunftsphasen und bei vielen Benutzern pro Maschine, laut Dokumentation Tausende pro CPU. Seine Grenzen sind eine ruhige Versionsgeschichte, Skripte nur in XML und keine eingebauten Pass/Fail-Prüfungen.

XMPP-, LDAP- und Datenbanktests auf Protokollebene, ohne Client-Code zu schreiben.
Verteilung über einfaches SSH, ohne Broker oder Zusatzdienst.
Servermonitoring im selben Bericht.
Logik jenseits des XML bedeutet Erlang, das nur wenige Teams schreiben.
Erlang muss auf dem Controller und auf jedem Client installiert sein.

Wann sollten Sie stattdessen k6, Gatling oder JMeter wählen?

Wählen Sie ein anderes Tool, wenn Sie HTTP oder APIs testen und ein aktives Projekt mit Skripten in einer verbreiteten Sprache wollen.

Wählen Sie k6 für JavaScript-Skripte mit im Skript eingebauten Schwellenwerten und ein aktives Projekt (geprüft am 21. Oktober 2026). Wählen Sie Gatling für Code-first-Simulationen auf der JVM; unser Gatling-Review behandelt es. Wählen Sie JMeter, wenn Tester eine GUI wollen oder Sie JDBC-, JMS- oder LDAP-Sampler mit einem großen Plugin-Ökosystem brauchen. LoadFocus führt JMeter und k6 aus 25 Cloud-Regionen aus, und der Überblick über Open-Source-Lasttest-Tools stellt diese Tools nebeneinander.

FAQ

Wird Tsung noch gepflegt? Ja, aber selten. Die letzte Version, 1.8.0, erschien am 2. März 2023, und das Repository erhält weiterhin gelegentlich zusammengeführte Änderungen, zuletzt im März 2026.

Welche Protokolle unterstützt Tsung? HTTP und SOAP, WebDAV, XMPP, PostgreSQL, LDAP und reines TCP, UDP oder SSL, dazu MySQL, WebSocket, AMQP und MQTT, die die Dokumentation als experimentell kennzeichnet.

Kann LoadFocus Tsung-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um einen Tsung-Test auf mehrere Maschinen zu verteilen, listen Sie diese als Clients in der XML-Datei auf.

Weiterlesen

Apdex-Score: was er bedeutet und wie man ihn berechnet

Mon, 19 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Ein Apdex-Score ist eine Zahl zwischen 0 und 1, die angibt, welcher Anteil der Anfragen schnell genug für die Wartenden war. Sie wählen eine Zielzeit T: Antworten bis T zählen voll, Antworten bis zum Vierfachen von T zählen halb, langsamere zählen null. Ein Ergebnis von 1 heißt, jede Anfrage hat das Ziel erreicht, 0 heißt, jede war zu langsam.

Zone	Antwortzeit	Gewicht im Score
Zufrieden (satisfied)	bis T	1
Tolerierend (tolerating)	über T, bis 4T	0,5
Frustriert (frustrated)	über 4T	0

Die Fakten unten stammen aus der Dokumentation und dem Quellcode der Tools, geprüft am 19. Oktober 2026.

Wie berechnet man einen Apdex-Score?

Addieren Sie die zufriedenen Anfragen und die Hälfte der tolerierenden und teilen Sie durch alle Anfragen. Das Ergebnis liegt immer zwischen 0 und 1.

Apdex(T) = (satisfied + tolerating / 2) / total

Die Apdex-Dokumentation von New Relic rechnet ein Beispiel mit T = 500 ms durch: Von 200 Anfragen waren 170 innerhalb von 500 ms fertig, 20 brauchten zwischen 500 ms und 2 Sekunden, und 10 schlugen fehl oder dauerten länger. Das ergibt (170 + 20 / 2) / 200 = 0,90 (geprüft am 19. Oktober 2026).

Ein zweites Beispiel zeigt, warum der Score im Lasttest nützlich ist. Ein Lauf schickt 10.000 Anfragen mit T = 300 ms: 8.200 sind innerhalb von 300 ms fertig, 1.300 zwischen 300 ms und 1,2 Sekunden, 500 dauern länger. Der Apdex beträgt (8.200 + 650) / 10.000 = 0,885. Derselbe Lauf kann leicht einen Durchschnitt von 280 ms melden, der für sich gut aussieht und die 500 Anfragen über einer Sekunde verbirgt.

Woher kommt Apdex?

Apdex, kurz für Application Performance Index, ist ein offener Standard einer Gruppe von Unternehmen, der Apdex Alliance. Peter Sevcik von NetForecast hat die Alliance 2004 gegründet.

Der Wikipedia-Artikel zu Apdex zitiert Sevciks Aufsatz von 2005 und nennt die 4T-Regel. Die Apdex Users Group schreibt inzwischen, die Regeln für die Schwellen T und F seien „flexibel geworden“ (geprüft am 19. Oktober 2026), und die Tools nutzen diese Freiheit.

Wie berechnen JMeter, Artillery und LoadFocus den Score?

Alle drei starten mit T = 500 ms. Sie unterscheiden sich darin, wo die tolerierende Zone endet und was mit fehlgeschlagenen Anfragen passiert, daher kann derselbe Lauf drei leicht verschiedene Werte ergeben.

Tool	Standard-T	Tolerierend bis	Fehlgeschlagene Anfragen
JMeter-HTML-Dashboard	500 ms	1.500 ms	zählen als frustriert
Artillery-Plugin `apdex`	500 ms	4T (2.000 ms)	nur Antworten werden bewertet
LoadFocus-Ergebnisseite	500 ms, fest	4T (2.000 ms)	nach Antwortzeit bewertet
New Relic APM	pro App einstellbar	4T	Serverfehler sind frustriert

JMeter. Der Dashboard-Bericht enthält eine APDEX-Tabelle pro Transaktion. Die Standardwerte sind jmeter.reportgenerator.apdex_satisfied_threshold=500 und apdex_tolerated_threshold=1500, die tolerierende Zone endet also bei 3T, solange Sie nichts ändern, und apdex_per_transaction setzt eigene Schwellen pro Sampler. In ApdexSummaryConsumer zählt ein fehlgeschlagenes Sample zur Gesamtzahl und nie zu den zufriedenen oder tolerierenden, jeder Fehler drückt also den Score (geprüft am 19. Oktober 2026).

Artillery. Das Apdex-Plugin funktioniert nur mit der HTTP-Engine und meldet die Zähler apdex.satisfied, apdex.tolerated und apdex.frustrated. Sein Quellcode in artillery-plugin-apdex 1.24.0 bewertet jede Antwort nach ihrer Gesamtzeit gegen T und 4T und gibt den Score mit einer Bezeichnung aus: excellent ab 0,94, good ab 0,85, fair ab 0,70, poor ab 0,49, darunter unacceptable. Eine Anfrage, die nie eine Antwort erhält, wird nie bewertet (geprüft am 19. Oktober 2026). Unser Artillery-Review behandelt das Tool selbst.

LoadFocus, der Herausgeber dieser Website, zeigt den Apdex-Score im Insights-Tab eines Lasttest-Ergebnisses neben einem Antwortzeit-Histogramm. T ist fest auf 500 ms eingestellt, die tolerierende Zone endet bei 2.000 ms, und T lässt sich nicht ändern. Jedes Sample wird nach seiner Antwortzeit eingeordnet, und die Anteile zufrieden, tolerierend und frustriert stehen neben dem Score.

Wie wählt man die Schwelle T?

Wählen Sie T danach, was die Nutzer dieser Seite oder dieses Endpunkts erwarten, und setzen Sie T pro Transaktion, wenn Ihr Tool das erlaubt. Ein einziges T für eine ganze Anwendung vermischt einen schnellen Suchendpunkt und einen langsamen Berichtsexport zu einer Zahl.

Ein paar praktische Regeln:

Starten Sie mit einem echten Ziel. Wenn Sie schon ein Latenzziel wie „95 % der Checkout-Aufrufe unter 400 ms“ haben, sorgt T = 400 ms dafür, dass Apdex und Ziel dasselbe erzählen.
Halten Sie T zwischen Läufen gleich. Ein Apdex ist nur mit einem Apdex bei gleichem T vergleichbar. Schreiben Sie Apdex(0.4) oder „Apdex bei T = 400 ms“, damit niemand über Schwellen hinweg vergleicht.
Gleichen Sie auch die tolerierende Zone an. Der JMeter-Standard endet bei 3T, die anderen bei 4T. Bevor Sie einen JMeter-Bericht mit einem anderen Tool vergleichen, setzen Sie apdex_tolerated_threshold auf das Vierfache von T.
Stellen Sie T nicht so ein, dass ein Release besteht. Wer T nach einem schlechten Lauf verschiebt, ändert das Lineal, und der beobachtete Trend ist weg.

Was ist ein guter Apdex-Score?

Das Artillery-Plugin nennt 0,94 und mehr excellent, 0,85 bis 0,94 good und alles unter 0,70 poor oder schlechter. Diese Bezeichnungen sagen nur etwas aus, wenn T ehrlich gewählt wurde.

Ein Apdex von 0,95 bei T = 2 Sekunden kann einen langsameren Dienst beschreiben als 0,80 bei T = 200 ms. Wenn Sie ein Release-Gate festlegen, schreiben Sie Schwelle und Score zusammen („Apdex(0.5) mindestens 0,9“) und prüfen Sie ihn neben einem Perzentil-Limit, denn beide fangen unterschiedliche Probleme ab.

Was verbirgt Apdex?

Er presst die ganze Antwortzeitverteilung in drei Kategorien und kann daher nicht sagen, wie langsam die frustrierten Anfragen waren. Eine Anfrage mit 2,1 Sekunden und eine mit 30 Sekunden senken den Score um genau denselben Betrag.

Deshalb wirkt er am besten neben anderen Zahlen:

Perzentile zeigen, wie langsam die langsamen Anfragen sind. Unser Leitfaden zur Tail-Latenz erklärt, warum das 99. Perzentil zählt, sobald eine Seite mehrere Dienste aufruft.
Die Fehlerrate erfasst Fehler, die Ihr Tool vielleicht nicht bewertet. Artillery bewertet Anfragen ohne Antwort nie, New Relic zählt Serverfehler als frustriert, lesen Sie die Fehlerzahl also separat.
Die Stichprobengröße zählt: New Relic weist darauf hin, dass der Score unter etwa 100 Anfragen pro Minute instabil ist.
Messverzerrung gibt es auch. Ein Lastgenerator, der auf langsame Antworten wartet, schickt in langsamen Phasen weniger Anfragen, und der Apdex sieht besser aus als die Wirklichkeit; siehe Coordinated Omission.

Wie setzt man Apdex im Lasttest ein?

Nutzen Sie ihn als Zusammenfassung für Leute, die kein Histogramm lesen, und treffen Sie die Pass/Fail-Entscheidung über ausdrückliche Limits.

Eine Routine, die funktioniert:

Setzen Sie T pro wichtiger Transaktion aus Ihrem Latenzziel.
Führen Sie den Test aus und notieren Sie den Apdex bei diesem T, dazu das 95. und 99. Perzentil und die Fehlerrate.
Vergleichen Sie den Apdex mit dem vorigen Lauf beim gleichen T. Ein Rückgang von 0,93 auf 0,86 ist auch für Leute außerhalb des Teams ein klares Signal.
Lassen Sie den Build an Perzentil- und Fehlerlimits scheitern, wie in unserem Leitfaden zu Pass/Fail-Kriterien für Lasttests beschrieben, und berichten Sie den Apdex daneben.

FAQ

Ist ein höherer Apdex-Score besser? Ja. 1,0 heißt, jede Anfrage war innerhalb von T fertig, und 0 heißt, jede Anfrage lag über der tolerierbaren Grenze oder wurde als frustriert gezählt.

Welche Apdex-Schwelle nutzt JMeter standardmäßig? Das HTML-Dashboard nutzt 500 ms für zufrieden und 1.500 ms für toleriert. Ändern Sie die Werte mit jmeter.reportgenerator.apdex_satisfied_threshold und apdex_tolerated_threshold.

Bezieht Apdex Fehler ein? Das hängt vom Tool ab. JMeter zählt fehlgeschlagene Samples als frustriert und New Relic Serverfehler ebenso, während das Artillery-Plugin nur Anfragen bewertet, die eine Antwort erhalten haben.

Kann man Apdex-Scores aus zwei Tools vergleichen? Nur wenn T, die tolerierbare Grenze und der Umgang mit Fehlern übereinstimmen. Sonst vergleichen Sie besser die zugrunde liegenden Perzentile und Fehlerraten.

Weiterlesen

Artillery-Lasttests: das Node.js-Tool im Überblick

Mon, 19 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Artillery ist ein Open-Source-Lasttest-Tool, das auf Node.js läuft und jeden Test als YAML-, TypeScript- oder JavaScript-Datei beschreibt. Ein Artillery-Lasttest passt zu Teams, die im JavaScript-Umfeld arbeiten, neue Benutzer mit fester Rate eintreffen lassen wollen oder Browsertests mit Playwright im selben Tool möchten. Wer ein einzelnes Binary ohne Laufzeitumgebung will, ist mit k6 besser bedient, und wer viele Protokolle ab Werk braucht, mit JMeter.

Wir haben Artillery für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation, dem Repository, dem npm-Paket und der Preisseite von Artillery, geprüft am 19. Oktober 2026; die Einschätzungen sind unsere eigenen.

Thema	Artillery
Lizenz	MPL-2.0; einige Azure-Module unter BSL
Laufzeit	Node.js, aktuelle LTS (Paket verlangt 22.18.0 oder neuer)
Aktuelle Version	2.0.34 (14. August 2026)
Tests als	YAML, TypeScript oder JavaScript
Lastmodell	Neue virtuelle Benutzer pro Sekunde, in Phasen
Eingebaute Engines	HTTP, WebSocket, Socket.IO, Playwright
Pass/Fail-Checks	Plugin `ensure`, Exit-Code ungleich null
Skalierung	`run-lambda`, `run-fargate`, `run-aci`
Gehostete Berichte	Artillery Cloud, optional, mit Gratisstufe

Wer entwickelt Artillery, und wie ist es lizenziert?

Artillery Software Inc. pflegt es auf GitHub. Der größte Teil des Codes steht unter MPL-2.0, die kommerzielle Nutzung erlaubt; einige Azure-spezifische Module stehen unter der Business Source License.

Das README des Repositorys erlaubt die Nutzung von Artillery auf Azure für Evaluierung und Proof of Concept und verlangt für kommerzielle oder produktive Nutzung dort eine kommerzielle Lizenz. Die neueste Version ist 2.0.34, am 14. August 2026 auf npm erschienen, und die Paketmetadaten verlangen Node.js 22.18.0 oder neuer; die Installationsanleitung empfiehlt die aktuelle LTS-Version (geprüft am 19. Oktober 2026).

Wie funktioniert ein Artillery-Testskript?

Ein Skript hat zwei Teile: config mit Ziel, Lastphasen und Plugins, und scenarios mit dem, was jeder virtuelle Benutzer tut. Sie können es in YAML schreiben oder config und scenarios aus einer TypeScript- oder JavaScript-Datei exportieren.

Dieser Test steigert in zwei Minuten von 5 auf 50 neue Benutzer pro Sekunde, hält zehn Minuten lang 50 pro Sekunde und scheitert, wenn das 99. Perzentil der Antwortzeit 800 ms erreicht:

config:
  target: https://staging.example.com
  phases:
    - duration: 120
      arrivalRate: 5
      rampTo: 50
      name: ramp
    - duration: 600
      arrivalRate: 50
      name: sustain
  plugins:
    ensure:
      thresholds:
        - http.response_time.p99: 800
scenarios:
  - name: browse and add to cart
    flow:
      - get:
          url: /products
      - think: 2
      - post:
          url: /cart
          json:
            sku: A-100

Laut Referenz zum Testskript gibt es vier Phasentypen: eine konstante Ankunftsrate, eine lineare Rampe mit rampTo, eine feste Zahl von Ankünften (arrivalCount) über einen Zeitraum und eine pause. Eigener Code über config.processor kann lokal und auf Fargate ein TypeScript-Modul sein, auf Lambda aber nicht (geprüft am 19. Oktober 2026).

Welches Lastmodell nutzt Artillery?

Artillery startet neue virtuelle Benutzer mit der Rate, die Sie festlegen, egal ob frühere Benutzer fertig sind. Das ist ein offenes Lastmodell, das die Ankünfte konstant hält, auch wenn das System langsamer wird.

Jeder neue Benutzer wählt ein Szenario, durchläuft es und geht, ein langsames System sammelt also Benutzer an, wie es echter Verkehr täte. maxVusers begrenzt die Zahl gleichzeitiger Benutzer in einer Phase, falls Sie den Lastgenerator schützen müssen. Unser Artikel zum offenen vs geschlossenen Lastmodell erklärt den Unterschied, und Little's Law zeigt, wie Ankunftsrate und Antwortzeit die Zahl gleichzeitiger Benutzer bestimmen.

Welche Protokolle und Browser kann es testen?

HTTP ist der Standard, WebSocket, Socket.IO und Playwright sind eingebaut. gRPC und AWS Kinesis brauchen separat installierte Engines.

Die Seite zu den Engines beschreibt das Modell: Jedes Szenario läuft auf einer Engine, und Sie können eigene schreiben. Auf npm steht artillery-engine-grpc bei 0.0.9 und artillery-engine-kinesis bei 1.1.1, beide unter MPL-2.0. Die Playwright-Engine führt Ihren Playwright-Code in echten Headless-Browsern aus und meldet Web Vitals wie TTFB, FCP und LCP pro Seite. Die Dokumentation warnt, dass ein eigener Browser pro Benutzer statt eines Browser-Kontexts deutlich mehr CPU und Speicher braucht (geprüft am 19. Oktober 2026). Unsere Übersicht der WebSocket-Lasttest-Tools stellt Artillery neben andere Optionen für Echtzeit-Apps.

Wie passt es in CI?

Das Plugin ensure macht aus Metriken Pass/Fail-Checks, und ein fehlgeschlagener Check lässt Artillery mit einem Exit-Code ungleich null enden. Das genügt jedem CI-System, um den Build scheitern zu lassen.

Die Referenz zu ensure bietet zwei Arten von Checks: thresholds, bei denen eine Metrik unter einem Wert bleiben muss, und conditions, die Metriken in einem Ausdruck wie http.response_time.p95 < 250 and http.request_rate > 1000 kombinieren. Eine Bedingung mit strict: false meldet nur, ohne zu scheitern. Das Apdex-Plugin ergänzt bei HTTP-Tests einen Apdex-Score mit einer Standardschwelle von 500 ms (geprüft am 19. Oktober 2026); unser Artikel zum Apdex-Score erklärt, wie man ihn liest. Für eine Workflow-Datei siehe unseren Leitfaden zu Lasttests in GitHub Actions.

Wie skaliert man einen Artillery-Test?

Von der Kommandozeile aus, im eigenen Cloud-Konto: run-lambda und run-fargate auf AWS, run-aci auf Azure Container Instances. Artillery legt die Ressourcen an, die der Lauf braucht, und entfernt die temporären danach.

Die Fargate-Anleitung listet die beteiligten Ressourcen und IAM-Berechtigungen. Die Lambda-Anleitung nennt ihre Grenzen: Ein Test kann nicht länger als 15 Minuten laufen, ein laufender Test lässt sich nicht stoppen, und before- und after-Hooks laufen einmal pro Worker. Die Azure-Anleitung verlangt Artillery 2.0.19 oder neuer und außerhalb einer Evaluierung ein Abonnement (geprüft am 19. Oktober 2026).

LoadFocus, der Herausgeber dieser Website, führt keine Artillery-Skripte aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen aus, für Artillery sind also die Befehle oben der Weg zum Skalieren.

Was kostet Artillery Cloud?

Das Dashboard ist optional: Ergebnisse landen nur dort, wenn Sie mit --record und einem API-Schlüssel starten. Die Pläne reichen von einer Gratisstufe bis 499 $ im Monat.

Die Preisseite nennt (geprüft am 19. Oktober 2026):

Free: 30 Berichte im Monat, 1 Monat Aufbewahrung, 2 Teammitglieder, verteilte Tests mit bis zu 5 Workern und 30 Minuten.
Team, 199 $ im Monat: 1.000 Berichte, 6 Monate, 8 Mitglieder, bis zu 25 Worker und 2 Stunden.
Business, 499 $ im Monat: 2.500 Berichte, 18 Monate, keine Grenze bei Mitgliedern, Workern oder Dauer.

Enterprise-SSO, Audit-Logs und Support-SLAs beginnen bei 1.199 $ im Monat, und jährliche Abrechnung spart 20 %.

Was kann Artillery gut, und wo liegen seine Grenzen?

Stark ist es bei Last mit fester Ankunftsrate, kurzen lesbaren Skripten und Browsertests mit Playwright. Schwächer ist es, wenn Sie ein einzelnes Binary, viele Protokolle ohne Zusätze oder Azure ohne Lizenz brauchen.

Als Node.js-Tool kann es in eigenen Funktionen jedes npm-Modul nutzen, um den Preis einer weiteren Laufzeitumgebung auf jeder Testmaschine. Grenzen, die die Dokumentation selbst nennt:

Lambda-Läufe enden nach 15 Minuten und lassen sich nicht abbrechen.
Eigener Code in TypeScript (config.processor) läuft nicht auf Lambda.
gRPC und Kinesis sind separate Engines.
Produktive Nutzung auf Azure erfordert eine kommerzielle Lizenz.

Wann sollten Sie stattdessen k6, JMeter oder Locust wählen?

Wählen Sie ein anderes Tool, wenn dessen Laufzeit, Protokolle oder Sprache besser zu Ihrem Team passen.

Wählen Sie stattdessen k6, wenn Sie ein Go-Binary ohne Node.js und Schwellenwerte im Skript wollen. Unser Vergleich k6 vs Artillery stellt beide nebeneinander. LoadFocus führt k6-Skripte aus 25 Cloud-Regionen aus, fährt Arrival-Rate-Szenarien aber mit einer festen Zahl von Benutzern; für eine gehaltene Ankunftsrate führen Sie sie mit k6 selbst aus.

Wählen Sie stattdessen JMeter, wenn Sie JDBC, JMS, LDAP oder FTP ab Werk brauchen oder wenn Ihre Tester Tests lieber in einer GUI erstellen.

Wählen Sie stattdessen Locust, wenn Ihr Team Python schreibt; unser Locust-Review behandelt es. Die Übersicht der Open-Source-Lasttest-Tools stellt alle nebeneinander.

FAQ

Ist Artillery für kommerzielle Nutzung kostenlos? Die CLI steht größtenteils unter MPL-2.0, die kommerzielle Nutzung erlaubt. Die Ausnahme ist Azure: Kommerzielle oder produktive Nutzung der Azure-Module erfordert eine kommerzielle Lizenz.

Kann Artillery Browsertests ausführen? Ja. Die eingebaute Playwright-Engine führt Ihren Playwright-Code in Headless-Browsern aus und meldet Web Vitals für jede Seite.

Kann LoadFocus Artillery-Skripte ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um einen Artillery-Test zu skalieren, nutzen Sie run-lambda, run-fargate oder run-aci.

Weiterlesen

Azure Load Testing: der Microsoft-Dienst im Überblick

Mon, 19 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Azure Load Testing ist der verwaltete Dienst von Microsoft, um JMeter- und Locust-Tests in großem Maßstab aus Azure auszuführen, abgerechnet pro virtueller Benutzerstunde. Er passt gut, wenn das getestete System auf Azure läuft, denn er kann Servermetriken aus Azure Monitor holen und private Endpunkte in einem virtuellen Netzwerk erreichen. Teams, die k6-Skripte schreiben, kein Azure-Abonnement haben oder von außerhalb der Azure-Regionen testen wollen, finden andere Dienste einfacher.

Wir haben Azure Load Testing für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation und der Preisseite von Microsoft, geprüft am 19. Oktober 2026; die Einschätzungen sind unsere eigenen.

Thema	Azure Load Testing
Art	Verwalteter Dienst im Azure-App-Testing-Hub
Test-Frameworks	Nur Apache JMeter und Locust
Ohne Code	URL-basierter Schnelltest, bis zu fünf HTTP-Anfragen
Skalierung pro Lauf	Bis zu 400 Engine-Instanzen
Längster Test	24 Stunden
Herkunft der Last	Region der Ressource oder bis zu 5 Regionen
Private Endpunkte	Ja, über VNet-Injektion
Preis	0,15 $ pro virtueller Benutzerstunde, 0,06 $ ab 10.000
Aufbewahrung	6 Monate; clientseitige Metriken 365 Tage

Was ist Azure Load Testing?

Ein vollständig verwalteter Dienst, der Ihren Lasttest auf Test-Engines von Microsoft ausführt, sodass Sie nie Lastgeneratoren aufbauen oder patchen. Sie legen in einer gewählten Azure-Region eine Load-Testing-Ressource an, fügen ihr Tests hinzu und starten Läufe aus dem Portal, der Azure CLI oder einer Pipeline.

Laut Übersichtsseite kann die getestete Anwendung überall laufen: in Azure, on-premises oder in einer anderen Cloud. Microsoft führt den Dienst inzwischen im Azure-App-Testing-Hub neben Playwright Workspaces; der Locust-Schnellstart legt die Ressource über diesen Hub an (geprüft am 19. Oktober 2026).

Welche Testarten und Tools unterstützt er?

Drei Wege: ein URL-basierter Schnelltest, ein hochgeladenes JMeter-Skript oder ein hochgeladenes Locust-Skript. Die Dokumentation sagt klar, dass kein anderes Test-Framework unterstützt wird.

Der Schnelltest nimmt bis zu fünf HTTP-Anfragen und eine Zielzahl virtueller Benutzer oder Anfragen pro Sekunde. Jede Engine bewältigt bis zu 250 virtuelle Benutzer, 400 Benutzer laufen also auf zwei Engines mit je 200.

Mit JMeter können Sie Plugins von jmeter-plugins.org nutzen oder eigene hochladen, und laut Übersicht funktioniert jedes Protokoll, das JMeter unterstützt, etwa eine Datenbankverbindung oder eine Message Queue. Mit Locust können Sie Locust-Plugins und andere Python-Bibliotheken hinzufügen. Die Locust-Dokumentation verweist selbst auf den Dienst als gehostete Option, und unser Locust-Review behandelt das Tool selbst. k6-, Gatling- und Artillery-Skripte laufen hier nicht (geprüft am 19. Oktober 2026).

Wie funktionieren Engines, virtuelle Benutzer und Limits?

Sie skalieren einen Test, indem Sie Engine-Instanzen hinzufügen. Bei JMeter ist die Gesamtlast die Zahl der Benutzer im Testplan mal die Zahl der Engines; bei Locust legen Sie die Gesamtzahl der Benutzer fest und wählen, wie viele Engines sie erzeugen.

Die Konzeptseite nennt beide Formeln, und die Seite zu den Dienstlimits legt die Obergrenzen pro Region und Abonnement fest (geprüft am 19. Oktober 2026):

Engine-Instanzen pro Testlauf: standardmäßig 1 bis 400 je nach Angebot, höchstens 400.
Gleichzeitige Engine-Instanzen: standardmäßig 5 bis 400, auf Anfrage bis 1.000.
Testdauer: standardmäßig 3 bis 24 Stunden, höchstens 24 Stunden.
Fehlerkriterien: bis zu 50 pro Test.
Aufbewahrung: serverseitige Metriken 90 Tage, clientseitige Metriken 365 Tage, Testergebnisse und Logs 6 Monate.

Ein höheres Standardlimit erfordert eine Supportanfrage; über die genannten Maximalwerte geht nichts hinaus.

Kann er private Endpunkte testen und Last aus mehreren Regionen erzeugen?

Ja, beides, mit einem Haken: Es lässt sich nicht kombinieren. Last aus mehreren Regionen funktioniert nur gegen öffentliche Endpunkte.

Standardmäßig laufen die Engines in der Region Ihrer Load-Testing-Ressource. Mit der Anleitung für mehrere Regionen wählen Sie bis zu 5 Regionen pro Test und verteilen die Last auf sie, und der Test wird dabei auf öffentlichen Verkehr umgestellt. Für Dienste ohne öffentlichen Endpunkt platziert die VNet-Injektion die Engines in dem Netzwerk, das die Anwendung enthält (geprüft am 19. Oktober 2026).

Was zeigen die Ergebnisse und Servermetriken?

Das Dashboard zeigt während des Laufs live clientseitige Metriken wie virtuelle Benutzer, Antwortzeit und Anfragen pro Sekunde. Für Apps auf Azure kommen serverseitige Metriken aus Azure Monitor, Application Insights und Container Insights auf derselben Zeitachse hinzu.

Diese Kombination ist der größte Vorteil des Dienstes: Sie sehen die Datenbank oder den Container, der genau dann an seine Grenze kommt, wenn die Antwortzeiten steigen, ohne ein separates Dashboard zu bauen. Die Anleitung zu serverseitigen Metriken beschreibt die Schritte. Frühere Läufe lassen sich nebeneinander vergleichen, und Sie können Ergebnisse für andere Tools herunterladen.

Wie funktionieren Pass/Fail-Kriterien und CI?

Sie setzen Fehlerkriterien auf Client- oder Servermetriken, und der Lauf gilt als fehlgeschlagen, sobald eines verletzt ist. Pipelines in Azure DevOps, GitHub Actions oder jedem CI-Tool, das die Azure CLI aufrufen kann, können einen Test starten und auf dieses Ergebnis prüfen.

Laut Anleitung zu Fehlerkriterien ist ein Kriterium ein Aggregat einer Clientmetrik, etwa durchschnittliche Antwortzeit oder Fehleranteil, verglichen mit einem Schwellenwert, entweder für den ganzen Test oder für eine benannte Anfrage. Für Servermetriken braucht die Ressource eine verwaltete Identität mit Lesezugriff. Auto-Stop beendet einen Lauf, wenn die Fehlerrate ein Limit überschreitet, damit eine falsche URL nicht weiter kostet. Die CI/CD-Anleitung behandelt GitHub Actions und Azure Pipelines (geprüft am 19. Oktober 2026). Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests erklärt, wie Sie die Limits wählen.

Was kostet Azure Load Testing?

Sie zahlen pro virtueller Benutzerstunde (VUH): 0,15 $ pro VUH für die ersten 10.000 VUH und 0,06 $ pro VUH danach, in jeder Region der Preisseite gleich. Seit dem 1. März 2026 gibt es zudem eine Mindestgebühr pro Testlauf.

Die Preisseite definiert eine VUH als virtuelle Benutzer mal Minuten, geteilt durch 60, gezählt alle 10 Sekunden; 1.000 Benutzer für 30 Minuten sind 500 VUH, also 75 $ zum Preis der ersten Stufe. Das Minimum sind 10 virtuelle Benutzer pro Engine für die Dauer des Laufs, mindestens 10 Minuten. Ein 3-stündiger Lauf mit 5 Benutzern auf einer Engine wird daher mit 30 VUH abgerechnet statt mit 15 (geprüft am 19. Oktober 2026).

Wann sollten Sie etwas anderes wählen?

Wählen Sie eine andere Option, wenn Ihre Skripte, Ihre Cloud oder Ihr Budget woandershin zeigen.

Unser Überblick über Open-Source-Lasttest-Tools behandelt die Tools, die Sie selbst betreiben können.

Wählen Sie stattdessen LoadFocus, den Herausgeber dieser Website, wenn Sie JMeter-Testpläne und k6-Skripte ohne Azure-Abonnement aus 25 Cloud-Regionen ausführen wollen. LoadFocus führt kein Locust aus und fährt k6-Arrival-Rate-Szenarien mit einer festen Zahl von Benutzern.

Wählen Sie stattdessen Grafana Cloud k6 oder den k6-operator, wenn Ihre Tests für k6 geschrieben sind, das Azure Load Testing nicht ausführen kann (geprüft am 19. Oktober 2026).

Wählen Sie stattdessen selbst betriebenes Locust, wenn Sie bereits Kubernetes oder freie Maschinen haben: Sein verteilter Modus ist kostenlos, und Sie zahlen nur die Hardware.

FAQ

Unterstützt Azure Load Testing k6? Nein. Er führt Apache-JMeter- und Locust-Tests aus, dazu URL-basierte Schnelltests, aus denen er selbst ein Skript erzeugt. k6-Skripte brauchen einen anderen Dienst oder eigene Infrastruktur.

Kann ich Azure Load Testing für eine App nutzen, die nicht auf Azure läuft? Ja. Die Test-Engines können jeden öffentlichen Endpunkt ansprechen. Serverseitige Metriken werden nur für Azure-Ressourcen erfasst, bei anderem Hosting lesen Sie Servermetriken aus Ihrem eigenen Monitoring.

Gibt es eine kostenlose Stufe? Die Preisseite nennt für Lasttests nur Preise pro Stunde, mit einem Minimum pro Testlauf. Neue Azure-Konten erhalten laut derselben Seite für die ersten 30 Tage ein Guthaben von 200 $.

Weiterlesen

Tail-Latenz: was sie ist und wie man sie misst

Mon, 19 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Tail-Latenz ist die Antwortzeit der wenigen langsamsten Anfragen, meist als 99. oder 99,9. Perzentil angegeben. Sie zählt, weil eine Nutzeraktion oft auf viele Anfragen wartet, sodass eine Verzögerung, die 1 von 100 Anfragen trifft, die meisten Ihrer Nutzer erreichen kann. Ein Lasttest, der nur Durchschnitt oder Median meldet, zeigt sie nicht.

Backend-Aufrufe pro Seite	Anteil der Seiten mit mindestens einem 1-von-100-langsamen Aufruf
1	1,0 %
5	4,9 %
10	9,6 %
20	18,2 %
50	39,5 %
100	63,4 %

Die Tabelle nimmt an, dass jeder Aufruf unabhängig von den anderen mit 1 % Wahrscheinlichkeit langsam ist: Der Anteil ist 1 - 0.99^n.

Was zählt zum Tail?

Der Tail ist der Teil der Antwortzeitverteilung oberhalb eines hohen Perzentils, meist p99 und p99,9. Der Median beschreibt eine typische Anfrage, der Tail die Anfragen, über die sich Leute beschweren.

Ein Perzentil ist eine Grenze: p99 = 800 ms heißt, 99 % der Anfragen brauchten 800 ms oder weniger und 1 % länger. Der Tail liegt in einem Antwortzeit-Histogramm rechts dieser Grenze, oft als langer, dünner Ausläufer weit weg vom Hauptgipfel. Unser Leitfaden zu Durchsatz vs. Latenz erklärt, wie Lasttest-Tools Latenz und Perzentile messen.

Warum ist Tail-Latenz so wichtig?

Weil sich Anfragen vervielfachen. Eine Seite oder ein API-Aufruf, der an viele Dienste verteilt wird, ist erst fertig, wenn der langsamste antwortet, und so wird der Tail jedes Dienstes zur typischen Erfahrung des Ganzen.

Die Standardquelle ist „The Tail at Scale“ von Jeffrey Dean und Luiz André Barroso, 2013 in Communications of the ACM erschienen (Paper als PDF, geprüft am 19. Oktober 2026). Ihr Beispiel: ein Server, der meist in 10 ms antwortet, beim 99. Perzentil aber eine Sekunde braucht. Berührt eine Anfrage einen solchen Server, ist 1 von 100 Nutzeranfragen langsam. Muss sie Antworten von 100 solchen Servern parallel einsammeln, dauern 63 % der Nutzeranfragen länger als eine Sekunde. Selbst wenn nur 1 von 10.000 Aufrufen langsam ist, sieht ein Dienst mit 2.000 Servern fast jede fünfte Anfrage über einer Sekunde.

Dean und Barroso berichten außerdem von Messungen aus einem echten Google-Dienst: Das 99. Perzentil für eine einzelne Leaf-Anfrage lag bei 10 ms, bis alle Leaf-Anfragen fertig waren aber bei 140 ms, und das Warten auf die langsamsten 5 % davon machte die Hälfte aus.

Was verursacht Tail-Latenz?

Meist Störungen durch andere Arbeit auf der Maschine oder im Netzwerk. Dieselbe Anfrage ist meist schnell und nur dann langsam, wenn gerade etwas anderes passiert.

Dean und Barroso nennen die üblichen Verdächtigen:

Geteilte Ressourcen: andere Arbeit auf derselben Maschine, die um CPU-Kerne, Prozessor-Caches, Speicher- oder Netzwerkbandbreite konkurriert.
Hintergrund-Daemons, die aufwachen und sich einen Teil der Maschine nehmen.
Wartungsarbeit wie Log-Kompaktierung oder Garbage Collection in verwalteten Laufzeitumgebungen.
Warteschlangen in Servern und Netzwerk-Switches, die jede andere Quelle verstärken.
Leistungs- und Temperaturgrenzen, die eine CPU nach einer Lastspitze bremsen.

Im Lasttest tauchen dieselben Punkte als GC-Pausen in JVM- oder Node.js-Diensten auf, als erschöpfter Verbindungspool, als langsame Datenbankabfrage, die nur manche Anfragen auslösen, als kalte Caches nach einem Deploy und als Wiederholungen nach einem Timeout. Ein Tail, der mit der Last wächst, deutet auf Warteschlangen; ein Tail, der schon bei geringer Last da ist, deutet auf etwas Periodisches wie GC oder einen geplanten Job.

Wie misst man Tail-Latenz im Lasttest?

Sammeln Sie genug Samples, fragen Sie Ihr Tool nach den richtigen Perzentilen und mitteln Sie Perzentile nie über Maschinen oder Zeitfenster.

Genug Samples. p99 wird vom langsamsten 1 % der Anfragen bestimmt, ein Lauf mit 500 Anfragen stützt ihn also auf 5 davon. Für ein stabiles p99 brauchen Sie Tausende Anfragen pro Transaktion, für p99,9 Zehntausende. Kurze Smoke-Tests eignen sich gut, um Fehler zu finden, und schlecht, um den Tail zu beurteilen.

Die richtigen Perzentile. Standardwerte hören oft vor dem Tail auf. Bei k6 ist summaryTrendStats standardmäßig avg,min,med,max,p(90),p(95), p99 erscheint also nur, wenn Sie es hinzufügen (k6-Optionsreferenz, geprüft am 19. Oktober 2026):

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

Der Aggregate Report von JMeter zeigt die 90-%-, 95-%- und 99-%-Linien, und die Properties aggregate_rpt_pct1 bis aggregate_rpt_pct3 legen fest, welche Perzentile erscheinen (geprüft am 19. Oktober 2026).

Keine gemittelten Perzentile. Das p99 eines ganzen Laufs ist weder der Durchschnitt der p99-Werte jeder Minute noch der Durchschnitt der p99-Werte jedes Lastgenerators. Führen Sie die Roh-Samples oder ein Histogramm zusammen und berechnen Sie das Perzentil einmal. Der Artikel zu Coordinated Omission behandelt HdrHistogram, das übliche Werkzeug dafür, und eine zweite Falle: Ein Lastgenerator, der auf langsame Antworten wartet, schickt weniger Anfragen, während das System langsam ist, und verbirgt genau den Tail, den Sie suchen.

LoadFocus, der Herausgeber dieser Website, zeigt pro Lauf P95- und P99-Kacheln, ein Antwortzeit-Histogramm aus den einzelnen Samples und die langsamsten Anfragen, sodass ein langer Ausläufer rechts vom Gipfel auf einen Blick sichtbar ist.

Wie setzt man ein Pass/Fail-Limit auf den Tail?

Setzen Sie ein Limit auf p99 pro wichtiger Transaktion, neben ein p95-Limit und ein Fehlerraten-Limit. Leiten Sie es aus dem ab, was die Nutzer dieser Transaktion brauchen, und lassen Sie den Lauf lang genug laufen, damit p99 stabil ist.

Eine sinnvolle Kombination für eine Checkout-API könnte lauten: p95 unter 400 ms, p99 unter 1.200 ms, Fehler unter 0,5 %. In k6 sind das Schwellenwerte auf http_req_duration wie p(99)<1200, und ein verletzter Schwellenwert lässt k6 mit einem Exit-Code ungleich null enden (k6-Thresholds, geprüft am 19. Oktober 2026). LoadFocus hat neben Max P95 ein Feld Max P99 response time für Cloud-, JMeter- und k6-Tests, und jeder Lauf wird dann mit PASS oder FAIL bewertet. Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests behandelt die übrigen Kriterien.

Wenn Sie auch einen Apdex-Score melden, denken Sie daran, dass er jede Anfrage über dem Vierfachen von T in dieselbe Kategorie wirft und einen Tail von 2 Sekunden nicht von einem mit 30 Sekunden unterscheiden kann. Das p99 kann es.

Wie senkt man Tail-Latenz?

Beseitigen Sie Quellen der Schwankung, wo es geht, und bauen Sie Aufrufer so, dass ein langsamer Aufruf nicht die ganze Antwort aufhält.

Übliche Maßnahmen, grob von günstig bis aufwendig:

GC und Poolgrößen abstimmen, damit Pausen und das Warten auf eine freie Verbindung unter Last kurz bleiben.
Reserve einplanen. Warteschlangen wachsen kurz vor der Sättigung stark, freie Kapazität verkürzt also den Tail; der Leitfaden zu Durchsatz vs. Latenz zeigt, wie Sie den Knick finden.
Timeouts setzen und Wiederholungen begrenzen, damit ein hängender Aufruf schnell scheitert, statt dass sich alles dahinter staut.
Abgesicherte Anfragen (Hedging) für idempotente Lesezugriffe nutzen: eine zweite Kopie an ein anderes Replikat schicken, wenn das erste nicht rechtzeitig antwortet. Dean und Barroso beschreiben, die Reserveanfrage erst nach der erwarteten Latenz des 95. Perzentils zu senden, was die Zusatzlast auf etwa 5 % begrenzt. In einem ihrer Tests senkte ein Hedge nach 10 ms das 99,9. Perzentil von 1.800 ms auf 74 ms, bei nur 2 % mehr Anfragen.
Weniger Fan-out. Weniger Backend-Aufrufe pro Seite heißt weniger Chancen, den Tail zu treffen, wie die Tabelle oben zeigt.

Führen Sie nach jeder Änderung denselben Test mit demselben Lastprofil erneut aus und vergleichen Sie p99 und p99,9 zwischen den Läufen.

FAQ

Ist Tail-Latenz dasselbe wie p99? p99 ist die üblichste Art, sie anzugeben, und der Tail ist das ganze langsame Ende der Verteilung. Verfolgen Sie auch p99,9 und das Maximum, wenn der Lauf genug Anfragen hat.

Warum ist mein p99 so viel höher als mein Durchschnitt? Weil ein paar langsame Anfragen den Durchschnitt kaum bewegen und das p99 vollständig bestimmen. Eine große Lücke ist normal; eine Lücke, die mit der Last wächst, deutet meist auf Warteschlangen.

Wie viele Anfragen brauche ich, um p99 zu messen? Mindestens einige Tausend pro Transaktion, damit das p99 auf Dutzenden langsamer Anfragen beruht. Für p99,9 planen Sie Zehntausende ein.

Weiterlesen

gRPC-Lasttest: Tools, Einrichtung und Kennzahlen

Fri, 16 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Für einen gRPC-Lasttest brauchen Sie ein Tool, das HTTP/2 und Protocol Buffers spricht: k6 und ghz können das von Haus aus, JMeter braucht ein Plugin, Gatlings gRPC-Unterstützung ist in der kostenlosen Edition begrenzt, und bei Locust müssen Sie selbst einen gRPC-Client einbinden. Werten Sie die Ergebnisse nach gRPC-Status aus, nicht nach HTTP-Status, denn fehlgeschlagene Aufrufe kommen trotzdem als HTTP 200 an, und prüfen Sie, ob die Last jedes Backend erreicht.

Für diesen Artikel wurde kein gRPC-Test ausgeführt. Die Fakten zu den Tools stammen aus der Dokumentation und den Repositories der jeweiligen Projekte, geprüft am 16. Oktober 2026; die Fakten zu LoadFocus stammen aus dessen Code.

Tool	gRPC-Unterstützung	Liest die API aus	Ratensteuerung
k6	Eingebaut (`k6/net/grpc`), unäre Aufrufe und Streams	`.proto`-Dateien oder Server Reflection	Arrival-Rate-Executors
ghz	Eigenes gRPC-Kommandozeilentool	`.proto`, Protoset oder Server Reflection	`--rps` und Lastpläne
JMeter	Plugin eines Drittanbieters (jmeter-grpc-request)	Einem Ordner mit `.proto`-Dateien	Thread Groups und Timer
Gatling	Eigene gRPC-Komponente; kostenlose Edition auf 5 Benutzer, 5 Minuten begrenzt	Mit protoc aus `.proto` generiertem Code	Injektionsprofile
Locust	Kein eingebauter Client; einen einbinden und Aufrufe melden	Ihrem Python-gRPC-Client	Wartezeiten, `constant_throughput`

Warum braucht gRPC einen anderen Lasttest als REST?

gRPC läuft über HTTP/2, sendet binäre Protocol Buffers statt JSON, legt das Ergebnis eines Aufrufs in einen Trailer statt in den HTTP-Status und bündelt viele Aufrufe auf einer Verbindung. Jeder dieser Punkte ändert, wie Sie den Test skripten oder seine Ergebnisse lesen.

Der Beitrag zum gRPC-Load-Balancing nennt die HTTP/2-Eigenschaften, auf die es hier ankommt: ein binäres Protokoll, viele Anfragen gemultiplext auf einer Verbindung und Header-Kompression, darüber stark typisierte Protobuf-Nachrichten (geprüft am 16. Oktober 2026). Ein Tool, das nur JSON über HTTP/1.1 sendet, kann keine gRPC-Methode aufrufen, prüfen Sie also zuerst die Protokollunterstützung.

Welches Tool sollten Sie verwenden?

Nehmen Sie k6, wenn Sie Szenarien, Checks und Schwellenwerte als Code wollen; nehmen Sie ghz für einen schnellen Benchmark einer Methode von der Kommandozeile. Greifen Sie zu JMeter, Gatling oder Locust, wenn Ihr Team alles andere bereits damit testet.

k6. Das Modul k6/net/grpc lädt Protobuf-Definitionen, baut Verbindungen auf, macht unäre Aufrufe mit invoke und öffnet Streams. Es meldet grpc_req_duration und die Zahl der Stream-Nachrichten in seinen Metriken.
ghz. Ein reines gRPC-Benchmark-Tool für die Kommandozeile. Zu seinen Optionen gehören --rps, --concurrency, --total und --duration, und wenn Sie weder --proto noch --protoset angeben, versucht es Server Reflection. Das neueste Release ist v0.121.0 (geprüft am 16. Oktober 2026).
JMeter. Der JMeter-Kern hat keinen gRPC-Sampler; das Plugin jmeter-grpc-request fügt einen hinzu, der einen Ordner mit .proto-Dateien liest, ohne Codegenerierung (neuester Tag v1.2.6, geprüft am 16. Oktober 2026).
Gatling. Die Gatling-README stellt gRPC, MQTT und GraphQL unter die Gatling Enterprise Component License, in der Community Edition begrenzt auf 5 gleichzeitige Benutzer und 5 Minuten Testdauer (geprüft am 16. Oktober 2026). Die Anleitung zur gRPC-Einrichtung generiert Code aus Ihren .proto-Dateien mit protoc.
Locust. Die Dokumentation zum Testen anderer Systeme enthält ein gRPC-Beispiel: Sie umhüllen einen gRPC-Client, damit jeder Aufruf an Locust gemeldet wird, und constant_throughput taktet eine Aufgabe auf höchstens eine feste Zahl von Läufen pro Sekunde.

Nehmen Sie ghz statt k6, wenn Sie nur wissen müssen, wie sich eine Methode bei einer bestimmten Rate verhält, und kein Skript schreiben wollen. Nehmen Sie stattdessen Locust, wenn Ihr Team in Python schreibt und der Test Logik braucht, die dort einfacher ist.

Wie schreiben Sie einen gRPC-Lasttest in k6?

Laden Sie die .proto-Datei im Init-Code, dann bauen Sie in jeder Iteration die Verbindung auf, rufen die Methode auf und prüfen den gRPC-Status. Der Aufbau folgt dem Beispiel aus der k6-Dokumentation.

import grpc from 'k6/net/grpc';
import { check } from 'k6';

const client = new grpc.Client();
client.load(['protos'], 'hello.proto');

export const options = { vus: 20, duration: '1m' };

export default () => {
  client.connect('grpc.example.com:443');
  const res = client.invoke('hello.Greeter/SayHello', {
    name: 'load test',
  });
  check(res, {
    'status is OK': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
};

Die Seite zu invoke nutzt dieselbe Abfolge aus Laden, Verbinden, Aufrufen, Prüfen und Schließen. connect verwendet TLS, außer Sie übergeben plaintext: true, und mit reflect: true fragt es den Server nach seiner API, statt eine .proto-Datei zu lesen (Verbindungsparameter). Um eine Anfragerate statt einer Benutzerzahl zu halten, führen Sie die Funktion in einem Arrival-Rate-Szenario aus.

Wie machen Sie einen schnellen Benchmark mit ghz?

Geben Sie ghz die Methode, einen Anfrage-Body und eine Rate oder Parallelität, und es gibt ein Latenz-Histogramm, Perzentile und eine Zählung pro Statuscode aus. Das passt für einen ersten Blick auf eine Methode.

ghz --insecure --proto ./hello.proto \
  --call hello.Greeter.SayHello \
  -d '{"name":"load test"}' \
  --rps 200 -c 50 -z 1m \
  localhost:50051

--rps setzt die angestrebte Anfragerate, verteilt auf die Worker, -c bestimmt, wie viele Worker es gibt, und -z die Dauer. Lassen Sie --proto weg, damit ghz Server Reflection nutzt, sofern der Server sie aktiviert hat. Die Ausgabeseite von ghz zeigt einen Beispielbericht.

Was sollten Sie in einem gRPC-Lasttest messen?

Messen Sie Latenz-Perzentile der Aufrufe, den Durchsatz und die Zahl jedes gRPC-Statuscodes. Eine Erfolgsquote auf HTTP-Ebene kann 100 % zeigen, während Aufrufe fehlschlagen, weil das Ergebnis im Trailer grpc-status steht.

Die gRPC-Spezifikation für HTTP/2 setzt den HTTP-Status auf :status 200 und überträgt das Ergebnis des Aufrufs in Trailern als grpc-status und grpc-message. Die Liste der Statuscodes enthält die Codes, die unter Last am meisten zählen:

DEADLINE_EXCEEDED (4): die Deadline lief ab, bevor der Aufruf fertig war.
RESOURCE_EXHAUSTED (8): ein Kontingent oder eine Ressource war erschöpft.
INTERNAL (13): eine interne Invariante ist verletzt, ein Code für schwere Fehler.
UNAVAILABLE (14): meist vorübergehend; ein erneuter Versuch mit Backoff kann helfen, ist bei nicht idempotenten Aufrufen aber nicht immer sicher.

Zählen Sie jeden Code pro Laststufe. Deadline-Fehler können steigen, während die erfolgreichen Aufrufe noch schnell aussehen, weil die langsamen an der Deadline abgebrochen werden, statt als langsam erfasst zu werden. Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests zeigt, wie Sie aus diesen Zahlen Schwellenwerte machen.

Warum landet die ganze Last auf einem Server?

Weil gRPC viele Aufrufe auf einer langlebigen Verbindung bündelt, schickt ein Load Balancer, der pro Verbindung arbeitet, jeden Aufruf darauf an dasselbe Backend. Ein Lastgenerator mit wenigen Verbindungen kann dann einen Server auslasten, während die anderen untätig sind.

Der Beitrag zum gRPC-Load-Balancing erklärt den Mechanismus. Ein Balancer auf Transportebene (L3/L4) terminiert die TCP-Verbindung und öffnet eine weitere zu einem gewählten Backend und kopiert die HTTP/2- und gRPC-Frames zwischen beiden; ein Balancer auf Anwendungsebene (L7) parst HTTP/2 und kann die Streams einer Client-Verbindung auf mehrere Backends verteilen. Laufen Ihre Produktions-Clients über einen L7-Balancer oder balancieren clientseitig, testen Sie über denselben Weg und prüfen Sie während des Laufs CPU und Anfragezahlen pro Backend.

Können Sie gRPC-Lasttests auf LoadFocus ausführen?

Nicht so, dass seine Berichte sie zeigen würden. LoadFocus führt das unveränderte k6-Release v0.57.0 aus, das das gRPC-Modul enthält, aber sein k6-Agent leitet nur HTTP-Anfragewerte an die Ergebnisse weiter, sodass gRPC-Aufrufe Last erzeugen würden, ohne in seinen Diagrammen oder Fehlerzahlen aufzutauchen.

Dazu kommen zwei weitere Grenzen. Der k6-Upload akzeptiert .js-, .ts-, .csv-, .txt-, .json-, .env- und .properties-Dateien, keine .proto-Dateien, ein Skript müsste sich also mit reflect: true verbinden. Und der Weg über JMeter ist verschlossen: Die JMeter-Agenten von LoadFocus bringen JMeter 5.6.2 mit vorinstallierten Plugins mit, unter denen kein gRPC-Sampler ist, und der JMeter-Upload akzeptiert keine Plugin-JAR-Dateien. Für gRPC führen Sie k6 oder ghz auf eigenen Rechnern aus und nutzen k6-Skripte auf LoadFocus für die HTTP-Seite desselben Systems, wo es Last aus 25 Regionen erzeugt.

FAQ

Kann man gRPC-Streaming-Aufrufe lasttesten? Ja, mit k6 und ghz. Das gRPC-Modul von k6 hat eine Klasse Stream mit write, end und Event-Handlern, und ghz hat Optionen für Streaming-Intervalle und -Dauern. Messen Sie gesendete und empfangene Nachrichten ebenso wie die Latenz der Aufrufe.

Braucht man die .proto-Datei, um einen gRPC-Dienst zu lasttesten? Nicht, wenn der Server Reflection aktiviert hat. k6 kann sich mit reflect: true verbinden, und ghz greift auf Reflection zurück, wenn Sie weder --proto noch --protoset angeben. Ohne Reflection brauchen Sie die .proto-Datei oder ein kompiliertes Protoset.

Warum erscheinen meine gRPC-Fehler nicht als fehlgeschlagene Anfragen? Weil der HTTP-Status eines gRPC-Aufrufs auch bei einem Fehler 200 ist. Das Ergebnis steht im Trailer grpc-status, prüfen Sie also diesen Wert in Ihrem Skript und zählen Sie jeden Code einzeln.

Weiterlesen

Durchsatz vs. Latenz: wie sie unter Last zusammenhängen

Fri, 16 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Durchsatz (Throughput) ist die Arbeit, die ein System pro Zeiteinheit erledigt, etwa Anfragen pro Sekunde. Latenz ist die Zeit, die eine einzelne Arbeitseinheit braucht, etwa 120 Millisekunden für eine Anfrage. Bei geringer Last beeinflussen sich beide kaum; nähert sich die Last der Kapazität des Systems, hört der Durchsatz auf zu steigen und die Latenz beginnt zu klettern, und genau diesen Punkt soll ein Lasttest finden.

Das Rechenbeispiel unten ist reine Arithmetik ohne Testlauf dahinter. Die Definitionen der Tools stammen aus der Dokumentation der jeweiligen Projekte, geprüft am 16. Oktober 2026.

	Durchsatz	Latenz	Bandbreite
Beantwortete Frage	Wie viel wird pro Sekunde fertig?	Wie lange dauert eine Einheit?	Wie viel könnte die Leitung tragen?
Typische Einheit	Anfragen oder Transaktionen pro Sekunde	Millisekunden	Megabit pro Sekunde
In k6	`http_reqs` (Anzahl und Rate)	`http_req_duration`	kein Testziel
In JMeter	Throughput	Elapsed time (und ein separates „Latency“)	kein Testziel

Was ist der Unterschied zwischen Durchsatz und Latenz?

Der Durchsatz zählt erledigte Arbeit über die Zeit; die Latenz misst die Zeit, die eine Arbeitseinheit braucht. Ein System kann eine niedrige Latenz und einen niedrigen Durchsatz haben oder einen hohen Durchsatz und eine hohe Latenz, deshalb brauchen Sie beide Zahlen, um es zu beschreiben.

Das JMeter-Glossar berechnet den Durchsatz als Zahl der Anfragen geteilt durch die Gesamtzeit, vom Start der ersten Probe bis zum Ende der letzten, einschließlich der Pausen zwischen den Proben, weil er die Last auf dem Server darstellen soll (geprüft am 16. Oktober 2026). Damit ist der Durchsatz eine Eigenschaft des ganzen Laufs, während die Latenz zu jeder Anfrage gehört und am besten als Verteilung gelesen wird: Median, p95, p99.

Ist Bandbreite dasselbe wie Durchsatz?

Nein. Bandbreite ist die größte Datenmenge, die eine Netzwerkverbindung tragen könnte; Durchsatz ist das, was tatsächlich durchkommt. Im Lasttest meint Durchsatz meist erledigte Anfragen, und die Bandbreite zählt erst, wenn große Nutzlasten die Leitung füllen, bevor der Anwendung die Kapazität ausgeht.

Die Vergleichsseite von AWS fasst die Netzwerksicht knapp: Latenz ist die Verzögerung in der Netzwerkkommunikation, Durchsatz die durchschnittliche Datenmenge, die über einen Zeitraum tatsächlich durchkommt, und Bandbreite das theoretische Maximum (geprüft am 16. Oktober 2026). Vieles, was Sie online dazu finden, meint diese Netzwerkbedeutung. Lasttests benutzen dieselben Wörter für Anfragen statt für Pakete, deshalb lohnt es sich zu sagen, welche Bedeutung ein Bericht meint.

Was bedeutet „Latenz“ in einem Lasttest-Tool?

Das hängt vom Tool ab. In JMeter ist Latency die Zeit bis zum ersten Teil der Antwort, die vollständige Antwortzeit heißt Elapsed time. In k6 umfasst http_req_duration Senden, Warten und Empfangen, und die Zeit bis zum ersten Byte ist eine eigene Metrik.

Das JMeter-Glossar misst die Elapsed time von kurz vor dem Senden der Anfrage bis kurz nach dem Empfang der letzten Antwort, die Latency dagegen bis kurz nach dem Empfang der ersten Antwort. Die k6-Metrikreferenz definiert http_req_duration als http_req_sending + http_req_waiting + http_req_receiving, ohne DNS-Auflösung und Verbindungsaufbau, und nennt http_req_waiting die Zeit bis zum ersten Byte (beides geprüft am 16. Oktober 2026). JMeters Latency entspricht also k6s http_req_waiting, nicht http_req_duration. Wer eine JMeter-„Latenz“ mit einer k6-„Duration“ vergleicht, sieht bei JMeter die bessere Zahl, ohne dass das System besser ist.

Wie verändern sich Durchsatz und Latenz, wenn die Last steigt?

Zuerst bedeutet mehr Last mehr Durchsatz, und die Latenz bleibt ungefähr gleich. Sobald das System seine Kapazität erreicht, wächst der Durchsatz nicht mehr, und jeder zusätzliche Benutzer fügt nur Wartezeit hinzu, also steigt die Latenz mit der Last.

Ein Rechenbeispiel, reine Arithmetik. Ein Dienst schafft höchstens 200 Anfragen pro Sekunde und antwortet in 0,1 Sekunden, wenn er nicht ausgelastet ist. Jeder virtuelle Benutzer sendet eine Anfrage und pausiert dann 1 Sekunde. Bei einer festen Zahl von Benutzern verbindet die Form von Little's Law für das geschlossene Modell die Größen: Benutzer = Anfragen pro Sekunde × (Latenz + Think Time), wie unser Artikel zu Little's Law Schritt für Schritt zeigt.

Virtuelle Benutzer	Durchsatz (Anfragen/s)	Latenz (s)
50	45	0,1
150	136	0,1
220	200	0,1
300	200	0,5
400	200	1,0
600	200	2,0

Bis 220 Benutzer wächst der Durchsatz im Gleichschritt mit ihnen. Danach bleibt er bei 200 stehen, und die Latenz muss den Rest aufnehmen: 300 Benutzer brauchen 300 ÷ 200 = 1,5 Sekunden pro Durchlauf, also bleiben 0,5 Sekunden Latenz. Echte Systeme verlaufen typischerweise sanfter, weil sich Warteschlangen schon vor der genauen Grenze bilden. Mit einem Arrival-Rate-Test ist das Bild härter: Kommen mehr als 200 Anfragen pro Sekunde an, wächst der Rückstau, solange der Überschuss anhält; den Unterschied erklärt der Artikel zum offenen vs. geschlossenen Lastmodell.

Wie finden Sie den Knick in Ihren eigenen Ergebnissen?

Erhöhen Sie die Last in Stufen, halten Sie jede Stufe lange genug, damit sie sich einpendelt, und notieren Sie für jede Stufe den Durchsatz und ein Latenz-Perzentil. Der Knick ist die erste Stufe, auf der der Durchsatz nicht mehr mit der Last steigt, während die Latenz zu klettern beginnt.

Einige Punkte machen diese Ablesung verlässlich:

Halten Sie jede Stufe einige Minuten, damit der Durchsatz auf einer stabilen Phase gemessen wird, nicht auf einer Rampe.
Lesen Sie ein Perzentil, nicht nur den Durchschnitt; ein Durchschnitt kann ruhig bleiben, während die langsamsten paar Prozent der Anfragen deutlich langsamer werden.
Prüfen Sie auf jeder Stufe die Fehler. Schnelle Fehlschläge zählen als erledigte Anfragen mit kurzen Zeiten, sodass ein fehlerhaftes System steigenden Durchsatz und sinkende Latenz zeigen kann.
Beobachten Sie den Lastgenerator. Ist seine CPU ausgelastet, ist die gefundene Grenze womöglich seine eigene.

Das Diagramm Antwortzeit gegen virtuelle Benutzer von LoadFocus zeigt die durchschnittliche und maximale Antwortzeit gegen die aktiven virtuellen Benutzer, ein Punkt pro erreichter Benutzerstufe; dort wird der Knick in einem gestuften Test sichtbar.

Lässt sich der Durchsatz steigern, ohne die Latenz zu erhöhen?

Manchmal. Mehr Kapazität verschiebt die Grenze, sodass die Latenz länger flach bleibt. Batching tauscht meist in die andere Richtung: Es erhöht den Durchsatz, indem einzelne Anfragen warten.

Der Nagle-Algorithmus von TCP ist das klassische Beispiel für diesen Tausch. RFC 896 hält neue Segmente zurück, solange frühere Daten auf der Verbindung noch nicht bestätigt sind, sodass das Netz weniger, vollere Pakete trägt und jeder kleine Schreibvorgang warten kann (geprüft am 16. Oktober 2026). Batching von Anfragen und Schreibpuffer funktionieren genauso: mehr pro Sekunde erledigt, mehr Zeit pro Element. Wenn Sie so etwas ändern, wiederholen Sie den gestuften Test und vergleichen Sie beide Kurven, nicht nur eine Zahl.

Welche der beiden gehört in Ihre Pass/Fail-Kriterien?

Beide, miteinander verknüpft. Ein Latenzziel sagt wenig ohne den Durchsatz, bei dem es gemessen wurde, und ein Durchsatzziel sagt wenig, wenn sich die Latenz dafür verdoppelt hat. Formulieren Sie sie als Paar, etwa p95 unter 300 Millisekunden bei 200 Anfragen pro Sekunde mit weniger als 1 % Fehlern.

Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests zeigt, wie Sie dieses Paar formulieren und automatisieren. Wartet Ihr Tool auf langsame Antworten, bevor es die nächste Anfrage sendet, können seine Latenzwerte das Problem untertreiben; Coordinated Omission erklärt, wie das passiert und wie Sie es vermeiden. Der Glossareintrag von LoadFocus zur Latenz zeigt, woher Latenz kommt und warum Perzentile zählen.

FAQ

Bedeutet niedrige Latenz einen hohen Durchsatz? Nicht unbedingt. Ein System kann jede Anfrage schnell beantworten, aber nur wenige gleichzeitig bearbeiten, oder viele gleichzeitig bearbeiten, während jede wartet. Sie wissen beides erst, wenn Sie beides unter derselben Last messen, am besten über mehrere Laststufen.

Was ist der Unterschied zwischen Latenz und Antwortzeit? Im Alltag meinen beide oft dasselbe. In JMeter ist Latency die Zeit bis zum ersten Teil der Antwort und Elapsed time die vollständige Antwortzeit, prüfen Sie also, welche ein Bericht zeigt, bevor Sie Tools vergleichen.

Warum steigt der Durchsatz in einem Lasttest nicht mehr? Etwas hat seine Grenze erreicht: CPU, eine Datenbank, ein Verbindungspool, ein Rate Limit oder der Lastgenerator selbst. Ab diesem Punkt stehen zusätzliche Benutzer nur noch an, was sich als steigende Latenz bei flachem Durchsatz zeigt.

Weiterlesen

Gatling vs Locust: JVM-Simulationen oder Python-Locustfiles?

Tue, 13 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Gatling und Locust sind beide kostenlose Open-Source-Tools, die Lasttests als Code in Ihrem Repository halten. Nehmen Sie Gatling, wenn Ihr Team auf der JVM arbeitet oder Sie offene und geschlossene Injektionsprofile, Assertions und einen HTML-Bericht in einem Paket wollen. Nehmen Sie Locust, wenn Ihr Team Python schreibt, eine Web-Oberfläche zum Starten und Beobachten eines Laufs schätzt und den verteilten Modus ohne kommerzielle Edition braucht.

Die Fakten in diesem Vergleich Gatling vs Locust stammen aus der Dokumentation und den Repositories der beiden Projekte, geprüft am 13. Oktober 2026.

	Gatling	Locust
Lizenz	Apache 2.0; gRPC, MQTT und GraphQL unter einer eigenen Komponentenlizenz (Repository)	MIT (Repository)
Laufzeit	JVM, OpenJDK LTS 11 bis 25 (Version 3.16.0)	Python 3.11 oder neuer (Version 2.46.7)
Testcode	Java, Kotlin, Scala, JavaScript oder TypeScript	Python
Eingebaute Protokolle	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP und HTTPS; weitere über einen Python-Client
Lastmodell	Offene oder geschlossene Injektionsprofile	Ein Pool von Benutzern, also ein geschlossenes Modell
Pass/Fail	Assertions, nach dem Lauf ausgewertet	Exit-Code 1 bei fehlgeschlagenen Anfragen oder ein eigener Listener
Berichte	HTML-Bericht nach jedem Lauf	Live-Diagramme in der Web-Oberfläche, CSV-Dateien, HTML-Bericht
Skalierung	Gatling Enterprise	Eingebauter Master mit Workern, Kubernetes-Operator

Was ist der Unterschied zwischen Gatling und Locust?

Gatling führt Simulationen auf der JVM aus, Locust führt gewöhnliche Python-Programme aus. Gatling bringt ein Lastmodell und einen Bericht von Haus aus mit, bei Locust schreiben Sie die Testlogik selbst.

Die README von Gatling beschreibt eine nicht blockierende Engine auf Basis von Netty und ein SDK in fünf Sprachen: Java, Kotlin und Scala laufen über Maven, Gradle oder sbt, JavaScript und TypeScript über ein eigenes SDK. Die Installationsseite verlangt ein 64-Bit-OpenJDK-LTS von 11 bis 25 und für das JavaScript-SDK Node.js 24 oder neuer.

Die README von Locust nennt es eine Möglichkeit, skalierbare Lasttests in reinem Python zu schreiben, und die Paketmetadaten verlangen Python 3.11 oder neuer. Die Seite What is Locust sagt, Locust sei ereignisbasiert auf gevent, sodass ein Prozess viele tausend gleichzeitige Benutzer bewältigen kann (geprüft am 13. Oktober 2026).

Wie schreibt man denselben Test in beiden Tools?

In Gatling verketten Sie Anfragen zu einem Szenario und geben ihm ein Injektionsprofil. In Locust schreiben Sie eine Benutzerklasse mit Tasks und einer Wartezeit dazwischen.

Fünfzig gleichzeitige Benutzer rufen die Benutzerliste ab und pausieren danach ein bis drei Sekunden, fünf Minuten lang. In Gatlings Java-SDK (Imports weggelassen):

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1, 3);

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

Derselbe Test in Locust:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

Die Referenz zur Injektion von Gatling nennt constantConcurrentUsers unter den Schritten des geschlossenen Modells. Locust bekommt Benutzerzahl und Laufzeit als Flags (geprüft am 13. Oktober 2026):

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

Wie modellieren Gatling und Locust die Last?

Gatling bietet offene und geschlossene Modelle, je nachdem, welche Methode Sie aufrufen. Locust arbeitet mit einem Pool von Benutzern und damit mit einem geschlossenen Modell.

Die Seite zu Lastmodellen von Gatling definiert geschlossene Systeme als solche mit begrenzter Zahl gleichzeitiger Benutzer und offene Systeme als solche, in denen Benutzer weiter eintreffen, egal wie langsam die Anwendung antwortet. Die meisten Websites seien offen. injectOpen nimmt Ankunftsraten, injectClosed nimmt Zielwerte für die Gleichzeitigkeit.

Im Locustfile-Leitfaden steht, dass die Wartezeit den Durchsatz nur begrenzen kann und keine neuen Benutzer startet, um eine Zielrate zu erreichen. Dauert ein Durchlauf länger als die Wartezeit erlaubt, fällt die Rate unter den Zielwert (geprüft am 13. Oktober 2026). Warum das wichtig ist, erklärt unser Leitfaden zum offenen vs geschlossenen Lastmodell.

Wie führt man einen Test aus, der größer ist als eine Maschine erzeugen kann?

Locust bringt den verteilten Modus mit. Die Open-Source-Edition von Gatling erzeugt Last von einer Maschine, verteilte Läufe brauchen Gatling Enterprise.

Locust startet einen Prozess mit --master und beliebig viele Prozesse mit --worker. Laut den Docs zur verteilten Last nutzt ein Python-Prozess nicht mehr als einen Kern, daher läuft ein Worker pro Kern, und --processes startet mehrere auf einer Maschine. Ein Kubernetes-Operator verwaltet verteilte Läufe in einem Cluster.

Die FAQ von Gatling sagt, die Community Edition unterstütze keine verteilten Tests, und die README beschreibt Enterprise als Betrieb auf verwalteten Lastgeneratoren oder privater Infrastruktur (geprüft am 13. Oktober 2026).

Es gibt einen Ausweg aus beiden. LoadFocus, der Herausgeber dieser Website, führt weder Gatling-Simulationen noch Locust-Tests aus. Wer keines von beiden im großen Maßstab betreiben möchte, kann dort k6-Skripte und JMeter-Testpläne aus 25 Cloud-Regionen laufen lassen. Der k6-Validator von LoadFocus warnt, dass Arrival-Rate-Szenarien dort mit einer festen Zahl von Benutzern laufen und deshalb keine Anfragerate halten. Der Umstieg von einem der beiden Tools bedeutet, den Test neu zu schreiben.

Wie entscheiden sie, ob ein Test bestanden ist, und welche Berichte gibt es?

Gatling wertet Assertions nach dem Lauf aus und schreibt jedes Mal einen HTML-Bericht. Locust beendet sich mit Exit-Code 1, wenn eine Anfrage fehlgeschlagen ist, und weitere Prüfungen ergänzen Sie als Listener.

Assertions in Gatling werden nach der Simulation ausgewertet, und eine einzige fehlgeschlagene Assertion lässt die Simulation scheitern. Der HTML-Bericht zeigt Perzentile der Antwortzeit, gestartete Benutzer pro Sekunde, gleichzeitige Benutzer und Anfragen pro Sekunde.

Laut den Headless-Docs von Locust endet der Lauf mit Exit-Code 1, wenn eine Stichprobe fehlgeschlagen ist, und ein Listener-Beispiel lässt den Lauf an Fehlerquote, durchschnittlicher Antwortzeit oder 95. Perzentil scheitern. Die Konfigurationsreferenz nennt --csv für Statistikdateien und --html für einen Bericht (geprüft am 13. Oktober 2026).

Welche Protokolle kann jedes Tool testen?

Gatling liefert mehr Protokolle mit, bei den neueren mit Grenzen. Locust liefert HTTP und HTTPS und erwartet für den Rest einen Python-Client.

Die README von Gatling führt HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events und JMS unter Apache 2.0 ohne Limits auf. gRPC, MQTT und GraphQL fallen unter die Gatling Enterprise Component License, und Tests damit sind in der Community Edition auf 5 gleichzeitige Benutzer und 5 Minuten begrenzt.

Die Seite zu anderen Systemen von Locust zeigt, wie man eine Protokollbibliothek einhüllt und jeden Aufruf meldet, mit Beispielen für gRPC und MQTT. Die Bibliothek muss mit gevent funktionieren, das I/O in kompiliertem C-Code nicht patchen kann, und locust-plugins ergänzt Benutzer für Kafka, Selenium und Playwright (geprüft am 13. Oktober 2026).

Welches Tool sollten Sie wählen?

Wählen Sie nach Sprache und danach, wie Sie das System belasten. Gatling passt zu JVM-Teams und Tests im offenen Modell, Locust zu Python-Teams und Tests mit eigener Logik.

Wählen Sie Gatling statt Locust, wenn Ihr Team auf der JVM zu Hause ist und Tests in Java, Kotlin oder Scala mit Maven, Gradle oder sbt bauen will, wenn Sie ein offenes Modell wie eine feste Ankunftsrate brauchen, wenn Sie JMS oder Server-Sent Events benötigen oder wenn Sie Assertions und einen Bericht ohne zusätzlichen Code wollen.

Wählen Sie Locust statt Gatling, wenn Ihr Team Python schreibt und Tests einen internen Python-Client wiederverwenden sollen, wenn Sie eine Web-Oberfläche wollen, um einen Lauf zu starten und die Last währenddessen zu ändern, wenn Sie den verteilten Modus im kostenlosen Tool brauchen oder wenn das System überwiegend wartende Benutzer sieht und es für Ihr Protokoll eine gevent-taugliche Python-Bibliothek gibt.

Für einen GUI-Testbuilder lohnt ein Blick auf JMeter, für ein einzelnes Binary ohne JVM oder Python auf k6.

FAQ

Ist Gatling schneller als Locust? Das haben wir nicht selbst gemessen, deshalb nennen wir keinen Sieger. Fair vergleichen lässt sich das nur mit demselben Szenario in beiden Tools auf Ihrer eigenen Hardware.

Kann Locust Gatling-Simulationen ausführen? Nicht laut der Dokumentation von Locust, die Tests nur als Python-Code beschreibt. Eine Gatling-Simulation muss als Locustfile neu geschrieben werden, und umgekehrt gilt dasselbe.

Kann LoadFocus Gatling- oder Locust-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um eine Gatling-Simulation auf mehrere Maschinen zu verteilen, nutzen Sie Gatling Enterprise, bei Locust den Master-Worker-Modus oder den Kubernetes-Operator.

Weiterlesen

JMeter vs Postman: welches Tool für Lasttests?

Tue, 13 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Postman ist ein API-Client für funktionale Prüfungen, Collections und Teamarbeit, der nachträglich einen Performancetest-Modus bekommen hat. Apache JMeter ist von Anfang an ein Lastgenerator. Nehmen Sie Postman, wenn Sie die vorhandene Collection für einen schnellen Lasttest oder einen Smoke-Test in der CI wiederverwenden wollen. Nehmen Sie JMeter, wenn Lasttests die eigentliche Aufgabe sind: viele Protokolle, große Benutzerzahlen, ausführliche Berichte und verteilte Lasterzeugung.

Die Fakten zu Postman stammen aus der Dokumentation und der Preisseite, die zu JMeter von der eigenen Website des Projekts, alle geprüft am 13. Oktober 2026.

	Postman	Apache JMeter
Hauptzweck	API-Client, funktionale Tests und Collections, mit Performance-Modus	Last- und Performancetests
Testdefinition	Eine Collection aus Anfragen mit Skripten und `pm.test()`-Assertions	Ein Testplan, in einer GUI gebaut und als `.jmx`-Datei gespeichert
Virtuelle Benutzer	Jeder durchläuft die Collection in einer Schleife; lokale Läufe sind durch Ihren Rechner begrenzt	Ein Java-Thread pro Benutzer in einer Thread Group
Lastprofile	Fixed, Ramp up, Spike und Peak	Thread Groups mit Ramp-up-Phase
Woher die Last kommt	Ihr Rechner oder CI-Runner, in bezahlten Tarifen Postmans Cloud	Ihr Rechner oder Remote-JMeter-Server, die Sie selbst betreiben
Kosten der Last	Lokale Läufe in allen Tarifen; Cloud-Läufe zu 0,04 $ pro Stunde und virtuellem Benutzer	Kostenlos, Apache-2.0-Lizenz
Pass/Fail in der CI	`postman performance run` mit `--pass-if`	CLI-Modus (`jmeter -n`)

Was leistet das Performance-Testing von Postman?

Es führt die Anfragen einer Collection mit mehreren virtuellen Benutzern parallel aus, für eine festgelegte Zahl von Minuten. Jeder Benutzer wiederholt die Anfragen der Reihe nach, und Ihre vorhandenen Skripte und Assertions laufen unter Last mit.

Laut der Dokumentation zum Performance-Testing ist die Collection für Ihre funktionalen Tests zugleich Ihr Lasttest, ohne separates Skript oder eigene Sprache (geprüft am 13. Oktober 2026). Sie wählen Dauer und Zahl der virtuellen Benutzer und dann ein Profil: Fixed, Ramp up, Spike oder Peak, wie die Konfigurationsseite beschreibt.

Wo liegen die Grenzen von Postman bei Lasttests?

Die wichtigste Grenze ist, woher die Last kommt. Ein lokaler Lauf ist durch den Rechner begrenzt, auf dem er läuft, und alles darüber hinaus braucht einen bezahlten Tarif.

Für lokale Läufe sagt die Dokumentation von Postman, dass die Zahl der virtuellen Benutzer von den verfügbaren Systemressourcen und der verwendeten Collection abhängt, dass Pre-request- und Post-response-Skripte die Zahl simulierbarer Benutzer senken und dass der Lauf stoppt, wenn der Rechner seine Ressourcenschwelle überschreitet. Als erster Test werden 10 bis 20 virtuelle Benutzer vorgeschlagen (geprüft am 13. Oktober 2026). Darüber kann der Lastgenerator selbst Ihre Messwerte verfälschen, weshalb Postman auch die Spitzenwerte von CPU und Arbeitsspeicher des Testrechners ausweist.

Die nächste Grenze sind Daten. CSV- und JSON-Dateien funktionieren laut derselben Konfigurationsseite nur bei lokalen Läufen, Datasets dagegen bei lokalen und Cloud-Läufen.

Was kostet Lasttesting mit Postman?

Lokale Performance-Läufe sind in jedem Tarif enthalten. Cloud-Läufe gibt es in bezahlten Tarifen und sie werden nutzungsabhängig in virtuellen Benutzerstunden abgerechnet.

Die Preisseite von Postman nennt unbegrenztes lokales Performance-Testing und Cloud-Performance-Testing zu 0,04 $ pro virtueller Benutzerstunde (geprüft am 13. Oktober 2026). Zu diesem Listenpreis sind 500 virtuelle Benutzer über eine Stunde 500 virtuelle Benutzerstunden, also 20 $, zusätzlich zur Tarifgebühr. Statische IP-Adressen, um Ziele hinter einer Firewall zu erreichen, gibt es nur im Enterprise-Tarif. Die Tarife selbst haben wir nicht bepreist, die aktuellen Gebühren pro Benutzer stehen auf der Seite.

Welche Protokolle lassen sich testen?

JMeter hat eine lange, dokumentierte Liste. Für Postman haben wir keine Liste der in Performance-Läufen unterstützten Protokolle gefunden und treffen deshalb keine Aussage dazu.

Die Startseite von JMeter nennt HTTP und HTTPS, SOAP und REST, FTP, Datenbanken über JDBC, LDAP, JMS-Messaging, SMTP-, POP3- und IMAP-Mail, native Befehle und Shell-Skripte, TCP und Java-Objekte (geprüft am 13. Oktober 2026). Postman beherrscht in der App weitere Anfragetypen wie GraphQL, gRPC und WebSocket, aber das sagt nicht, welche davon unter Last laufen. Probieren Sie einen Typ aus, bevor Sie sich darauf verlassen.

Wie skaliert man über einen Rechner hinaus?

Postman skaliert über die eigene Cloud, JMeter über Server, die Sie selbst betreiben. Das Erste ist einfacher zu starten, das Zweite gibt Ihnen Kontrolle.

In bezahlten Tarifen verteilen die Cloud-Läufe von Postman die Last auf verwaltete Worker, sodass ein einzelner Rechner den Test nicht mehr begrenzt. Der Remote-Modus von JMeter lässt einen Client viele JMeter-Server steuern. Jeder Knoten braucht dieselbe JMeter-Version, einen Keystore für RMI über SSL, sofern Sie es nicht abschalten, und eine eigene Kopie aller Datendateien (geprüft am 13. Oktober 2026).

Für JMeter-Testpläne gibt es einen dritten Weg. LoadFocus, der Herausgeber dieser Website, führt vorhandene JMeter-Testpläne aus 25 Cloud-Regionen aus. Sie laden die .jmx-Datei hoch und legen virtuelle Benutzer, Dauer und Ramp-up fest, ganz ohne Remote-Server. LoadFocus führt nur JMeter und k6 aus, eine Postman-Collection also nicht.

Welches Tool sollten Sie wählen?

Wählen Sie Postman statt JMeter für funktionale und Contract-Prüfungen, für ein Team, das Collections in einem Workspace teilt, und für einen schnellen Smoke-Lauf einer API, die Sie ohnehin testen. Wählen Sie JMeter, wenn Lasttests das Hauptziel sind oder wenn Sie mehrere Protokolle, große Benutzerzahlen oder Tests im eigenen Repository brauchen.

Postman passt zu einem kurzen Check in der CI: postman performance run endet mit einem Exit-Code ungleich null, wenn ein Schwellenwert wie das 95. Perzentil verfehlt wird, und lässt so den Build scheitern. JMeter ist die bessere Wahl für Last auf Datenbanken oder Messaging, für lange Soak-Tests und für das HTML-Dashboard mit APDEX- und Perzentil-Tabellen, das seine Dokumentation beschreibt.

Viele Teams nutzen beide: Postman, um die API-Prüfungen zu bauen und zu verifizieren, JMeter, um den kritischen Abläufen echte Last zu geben.

FAQ

Kann Postman JMeter für Lasttests ersetzen? Für kleine Prüfungen von HTTP-APIs ja, denn die vorhandene Collection ist der Test. Bei hoher Parallelität, anderen Protokollen oder langen Läufen sprechen die dokumentierten Grenzen lokaler Läufe und die nutzungsabhängigen Preise der Cloud-Läufe für JMeter als sicherere Basis.

Kann Postman eine JMeter-.jmx-Datei ausführen? In der Dokumentation haben wir nichts gefunden, was einen JMeter-Testplan importiert. Postman-Performancetests entstehen aus Collections, eine .jmx-Datei müsste also neu aufgebaut werden.

Ist JMeter kostenlos? Ja. Die aktuelle Version auf der Download-Seite ist 5.6.3 und braucht Java 8 oder neuer (geprüft am 13. Oktober 2026). Sie zahlen für die Rechner, die Last erzeugen, oder für einen Cloud-Dienst, der Ihre Pläne ausführt.

Weiterlesen

k6 vs Locust: JavaScript-Skripte oder Python-Nutzer?

Tue, 13 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

k6 und Locust sind beide Open-Source-Tools, die einen Lasttest als Code in Ihrem Repository halten, und mit beiden lässt sich eine HTTP-API gut unter Last testen. Nehmen Sie Locust, wenn Ihr Team Python schreibt und die Testlogik in reinem Python haben möchte. Nehmen Sie k6, wenn Sie JavaScript schreiben, Schwellenwerte für Pass/Fail eingebaut haben wollen oder einen Test brauchen, der eine Ankunftsrate hält.

Die Angaben in diesem Vergleich von k6 und Locust stammen aus der Dokumentation und dem Repository des jeweiligen Projekts, geprüft am 13. Oktober 2026.

	k6	Locust
Lizenz	AGPL-3.0 (Repository)	MIT (Repository)
Laufzeit	Ein Go-Binary mit eingebetteter JavaScript-Engine (Release v2.3.0)	Python 3.11 oder neuer (Release 2.46.7)
Testskripte	JavaScript oder TypeScript, bei dem die Typen entfernt werden	Python-Klassen in einem Locustfile
Eingebaute Protokolle	HTTP/1.1, HTTP/2, WebSockets, gRPC	HTTP und HTTPS
Lastmodell	Sechs Executors, davon zwei Arrival-Rate (offenes Modell)	Ein Pool von Nutzern, die jeweils eine Wartezeit einlegen (geschlossenes Modell)
Pass/Fail	Schwellenwerte, die einen Lauf vorzeitig abbrechen können	Exit-Code 1 bei fehlgeschlagenen Anfragen; weitere Grenzen per Listener
Browsertests	Eingebautes Browser-Modul	Browser-Nutzer über das separate Projekt locust-plugins
Skalierung	k6-operator auf Kubernetes oder Grafana Cloud k6	Master und Worker, ein Kubernetes-Operator oder Azure Load Testing

Was ist der Unterschied zwischen k6 und Locust?

Der Hauptunterschied ist die Sprache, in der Sie Tests schreiben. k6 führt JavaScript in einem kompilierten Go-Programm aus, während Locust Ihren Python-Code ausführt und für viele gleichzeitige Nutzer auf gevent aufbaut.

k6 wird als Paket oder eigenständiges Binary ohne weitere Laufzeit installiert. Es führt auch .ts-Dateien aus, doch seine TypeScript-Unterstützung entfernt die Typen, ohne sie zu prüfen. Locust installieren Sie mit pip install locust, und laut der Seite What is Locust sind Tests gewöhnlicher Python-Code, den Sie wie jeden anderen Code in der Versionsverwaltung halten (geprüft am 13. Oktober 2026).

Wie schreibt man denselben Test in beiden Tools?

Beide drücken den Test als kurzes Programm aus. Hier ein Test mit 50 Nutzern über fünf Minuten, der fehlschlägt, wenn das 95. Perzentil über 500 ms liegt oder mehr als 1 % der Anfragen scheitern.

In k6 gehören die Ziele zum Skript, als Schwellenwerte:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

In Locust ist der Nutzer eine Klasse, und dieselben Ziele stehen in einem Listener, nach dem Muster aus den Docs zum Headless-Modus:

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

Gestartet werden sie mit k6 run script.js und locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (geprüft am 13. Oktober 2026).

Wie modellieren k6 und Locust die Last?

k6 unterstützt beide Lastmodelle, während Locust die Last als feste Zahl von Nutzern beschreibt. In k6 wählen Sie das Modell über den Executor, in Locust über Nutzerzahl und Wartezeit.

k6 hat sechs Executors. Vier davon sind geschlossen: Ein virtueller Benutzer startet seine nächste Iteration erst, wenn die letzte beendet ist. Die zwei Arrival-Rate-Executors folgen dem offenen Modell, in dem Iterationen unabhängig davon starten, wie lange frühere dauern. Der Locustfile-Leitfaden sagt, dass die Wartezeit den Durchsatz nur begrenzen und keine neuen Nutzer starten kann, um eine Zielrate zu erreichen (geprüft am 13. Oktober 2026).

Lautet Ihr Ziel "300 Anfragen pro Sekunde, egal wie die Antwortzeit ausfällt", kann k6 das direkt ausdrücken. Unser Leitfaden zum offenen und geschlossenen Lastmodell erklärt, wann welches Modell passt.

Wie entscheiden k6 und Locust, ob ein Test bestanden ist?

k6 hat Pass/Fail-Kriterien als Kernfunktion, Locust überlässt das meiste Ihrem Code. Ein verletzter k6-Schwellenwert beendet den Lauf mit einem Exit-Code ungleich null, und abortOnFail stoppt den Test in dem Moment, in dem er scheitert.

Locust beendet sich mit Exit-Code 1, wenn eine Anfrage fehlgeschlagen ist. Für Grenzen bei der Fehlerquote, dem Durchschnitt oder dem 95. Perzentil zeigen die Docs einen Listener wie den oben, der den Exit-Code selbst setzt (geprüft am 13. Oktober 2026). Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests hilft bei der Wahl der Grenzen.

Welche Protokolle deckt jedes Tool ab?

k6 liefert vier Protokolle und ein Browser-Modul mit, Locust liefert HTTP und HTTPS mit und lässt Sie jeden Python-Client für den Rest einbinden.

k6 nennt HTTP/1.1, HTTP/2, WebSockets und gRPC als eingebaute Protokolle, weitere über xk6-Erweiterungen, dazu ein Browser-Modul, das einen Chromium-basierten Browser steuert. Laut Locusts Seite zu anderen Systemen bringt es eingebaute Unterstützung nur für HTTP/HTTPS mit, lässt sich aber erweitern, um fast jedes System zu testen: Man umhüllt eine Protokollbibliothek und meldet jeden Aufruf als Anfrage. Die Bibliothek muss mit gevent zusammenarbeiten (geprüft am 13. Oktober 2026).

Wie fährt man einen größeren Test, als eine Maschine erzeugen kann?

Locust skaliert mit einem Master und Workern, k6 mit einem Kubernetes-Operator oder einem gehosteten Dienst. Beide können einen Test auf viele Maschinen verteilen.

Die Docs zum verteilten Betrieb von Locust sagen, ein Prozess schaffe bei einem einfachen Testplan mehr als tausend Anfragen pro Sekunde; größere Tests laufen daher mit einem Worker pro Prozessorkern auf so vielen Maschinen wie nötig. Der k6-operator verteilt einen Test auf mehrere k6-Instanzen in einem Kubernetes-Cluster, und Grafana Cloud k6 ist der gehostete Weg (geprüft am 13. Oktober 2026).

Für k6-Skripte gibt es einen dritten Weg. LoadFocus, der Herausgeber dieser Seite, führt k6-Skripte aus 25 Cloud-Regionen aus, wobei Nutzer und Dauer aus den Einstellungen des Tests stammen. Der Skript-Validator warnt, dass Arrival-Rate-Szenarien dort mit einer festen Zahl von Nutzern laufen; ein Skript im offenen Modell hält seine Ankunftsrate bei LoadFocus also nicht. LoadFocus führt Locust nicht aus: Es führt nur k6-Skripte und JMeter-Testpläne aus.

Welche Berichte erhält man?

k6 gibt eine Zusammenfassung am Ende des Tests aus und kann aus seinem Web-Dashboard einen HTML-Bericht exportieren. Locust zeigt Live-Diagramme in der Web-UI und schreibt auf Wunsch Dateien.

Die Zusammenfassung am Testende von k6 erscheint im Terminal, und das Web-Dashboard exportiert einen eigenständigen HTML-Bericht, wenn Sie K6_WEB_DASHBOARD_EXPORT setzen. Locust stellt eine Web-UI auf Port 8089 mit Live-Diagrammen bereit, und die Konfigurationsreferenz führt die Ausgaben --csv, --html und --json auf (geprüft am 13. Oktober 2026).

Welches Tool sollten Sie wählen?

Locust passt zu Python-Teams, k6 zu Teams, die eingebaute Schwellenwerte und ein offenes Lastmodell wollen. Protokolle und Skalierung entscheiden die meisten übrigen Fälle.

Wählen Sie Locust statt k6, wenn Ihr Team Python schreibt und Schleifen, Verzweigungen, generierte Daten und einen eigenen API-Client in reinem Python haben möchte, wenn Sie Python-Bibliotheken für ein Protokoll wiederverwenden wollen oder wenn Sie eine Web-UI mit Live-Diagrammen nutzen möchten, um ein System zu erkunden. Wählen Sie k6 statt Locust, wenn Ihr Team JavaScript oder TypeScript schreibt, wenn Schwellenwerte einen CI-Build scheitern lassen und einen schlechten Lauf früh stoppen sollen, wenn Sie eine konstante Ankunftsrate brauchen oder wenn gRPC und Browsertests im selben Tool liegen sollen.

Einen breiteren Blick bietet unser Überblick über Locust-Lasttests.

FAQ

Ist Locust schneller als k6? Wir haben das nicht selbst gemessen, also nennen wir keinen Sieger. Der faire Test ist dasselbe Szenario mit beiden Tools auf Ihrer eigenen Hardware.

Kann Locust k6-Skripte ausführen? Laut den Locust-Docs nicht, sie beschreiben Tests als Python-Code in einem Locustfile. Ein k6-Skript ist JavaScript und muss daher als Python-Nutzerklasse neu geschrieben werden; aus den Schwellenwerten wird ein Listener.

Kann LoadFocus Locust-Tests ausführen? Nein. LoadFocus führt k6-Skripte und JMeter-Testpläne aus. Um einen Locust-Test zu skalieren, nutzen Sie dessen Master-Worker-Betrieb, den Kubernetes-Operator oder Azure Load Testing.

Weiterlesen

Coordinated Omission: was es ist und wie man es vermeidet

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Coordinated Omission ist ein Messfehler: Ein Lastgenerator wartet auf jede langsame Antwort, bevor er die nächste Anfrage sendet, schickt also gerade dann weniger, wenn das System langsam ist, und erfasst zu wenige der schlechten Momente. Die Perzentile, die Sie danach ablesen, sehen deshalb besser aus als das, was die Nutzer erlebt haben. Sie vermeiden ihn, indem Sie Anfragen nach einem Zeitplan senden, der Antwortzeiten ignoriert, und jede Anfrage ab dem Moment messen, zu dem sie hätte rausgehen sollen.

Die Fakten zu den Tools stammen aus der Dokumentation oder dem Repository des jeweiligen Projekts, geprüft am 9. Oktober 2026.

Tool	Was es bietet	Was Sie prüfen sollten
wrk2	Konstante Rate (`-R`), Latenz ab dem geplanten Sendezeitpunkt	`--u_latency` zeigt zusätzlich die unkorrigierte Sicht
HdrHistogram	Zwei Methoden, die fehlende Messwerte auffüllen	Nur eine davon anwenden, nie beide
k6	Arrival-Rate-Executors	Den Zähler `dropped_iterations`
Gatling	`injectOpen`-Schritte wie `constantUsersPerSec`	Die Schritte stehen in `injectOpen`
Locust	`constant_throughput` taktet jeden Nutzer	Die erreichte Rate im Vergleich zum Ziel
JMeter	Open Model Thread Group (ab 5.5, experimentell)	Eine normale Thread Group ist ein geschlossener Pool

Was ist Coordinated Omission?

Der Fehler entsteht, wenn die messende Seite keine Messwerte mehr erfasst, weil das System langsam ist, sodass genau die langsamen Messwerte fehlen. Zufällig verlorene Messwerte verschieben ein Perzentil kaum; gehen sie im Gleichschritt mit einer Verlangsamung verloren, verzerrt das alle Perzentile.

Der Name stammt von Gil Tene, dessen Beitrag auf einer Mailingliste von 2013 genau diese Grenze zieht. Er ist der ursprüngliche Autor von HdrHistogram, wrk2 liegt in seinem GitHub-Konto, und die Dokumentation beider Projekte erklärt den Effekt (geprüft am 9. Oktober 2026). Die k6-Dokumentation verwendet den Begriff für ein geschlossenes Lastmodell, das seine eigene Last drosselt, eine häufige Ursache. Unser Artikel zum offenen vs geschlossenen Lastmodell behandelt diese Wahl, hier geht es um die Messung.

Wie verbirgt ein Lasttest langsame Antworten?

Ein Generator mit geschlossener Schleife sendet die nächste Anfrage auf einer Verbindung erst, wenn die vorherige Antwort da ist. Dauert eine Antwort eine Sekunde, sendet diese Verbindung eine Sekunde lang nichts, und die Anfragen, die sie in dieser Zeit gesendet hätte, bekommen nie eine Antwortzeit.

Das README von wrk2 sagt das über das Modell von wrk, das jede Anfrage vom ersten gesendeten Byte bis zur vollständigen Antwort misst: Weil eine Verbindung erst nach einer Antwort sendet, stimmt sich der Generator mit dem Server ab und misst in Phasen hoher Latenz nicht (geprüft am 9. Oktober 2026).

Das README von HdrHistogram bietet ein Gedankenexperiment. Ein System, das alle 10 ms gemessen wird, antwortet 100 Sekunden lang in 1 ms und hängt dann 100 Sekunden lang, wobei ein einziger Messwert von 100 Sekunden entsteht. Das Roh-Histogramm zeigt etwa 99,99 % der Ergebnisse bei 1 ms oder darunter; korrigiert um die blockierten Messwerte ist es nur etwa die Hälfte.

Woran erkennen Sie Coordinated Omission in Ihren Ergebnissen?

Vergleichen Sie die gesendete Rate mit der geplanten. Ist die Anfragerate gefallen, während die Antwortzeiten stiegen, hat der Generator zurückgesteckt, und die langsame Phase ist unterrepräsentiert.

Die Last war als Nutzer oder Verbindungen ohne Rate definiert. Jede geschlossene Schleife kann den Fehler auslösen.
Die Anfragerate sinkt dort, wo die Antwortzeiten steigen. Ein Einbruch der Rate während einer Spitze heißt, dass Anfragen nie gesendet wurden.
Das Maximum stellt das 99. Perzentil weit in den Schatten. Ein paar riesige Messwerte zwischen Tausenden schnellen sind das Beispiel oben im Kleinen. Lesen Sie die gesamte Antwortzeitverteilung und denken Sie daran, dass sie nur gesendete Anfragen zählt.
Dem Lastgenerator fehlte CPU. LoadFocus dokumentiert, dass eine Engine nahe 100 % CPU nicht mit der eingestellten Rate senden kann, und die Ergebnisse zeigen eine Warnung zur Sättigung des Lastgenerators, wenn eine Engine in der Spitze 80 % CPU oder mehr erreicht hat.

Wie vermeidet wrk2 Coordinated Omission?

Es sendet mit konstanter Rate und misst jede Anfrage ab dem Zeitpunkt, zu dem sie laut Plan hätte rausgehen sollen. Eine Anfrage, die zu spät losgeht, weil ihre Verbindung belegt war, bekommt die Wartezeit angerechnet.

wrk2 ergänzt wrk um ein Raten-Argument (-R, Anfragen pro Sekunde insgesamt) und erfasst Latenzen in einem HdrHistogram. --u_latency fügt dem Bericht das unkorrigierte Histogramm hinzu, markiert mit CO, wie im Beispiel aus dem README:

wrk -t2 -c100 -d30s -R2000 --u_latency http://127.0.0.1:80/index.html

Im zweiten Beispiel des README machte eine Serverpause von 1,4 Sekunden während eines 30-Sekunden-Laufs das korrigierte 99. Perzentil 200-mal so groß wie das unkorrigierte. Das README nennt das Projekt außerdem experimentell und warnt, dass Läufe unter 10 bis 20 Sekunden womöglich nichts Brauchbares liefern (geprüft am 9. Oktober 2026). Unser Überblick über HTTP-Benchmark-Tools vergleicht wrk2 mit hey, oha und weiteren Tools.

Wie korrigiert HdrHistogram aufgezeichnete Latenzen?

Wenn Sie das Intervall kennen, in dem Anfragen rausgehen sollten, ergänzt es die Messwerte, die eine lange Antwort blockiert hat. Die Korrektur geht beim Aufzeichnen oder nachträglich an einer Kopie.

recordValueWithExpectedInterval zeichnet einen Wert auf und fügt, wenn er das Intervall übersteigt, Werte hinzu, die in Schritten dieses Intervalls kleiner werden. copyCorrectedForCoordinatedOmission liefert eine korrigierte Kopie eines fertigen Histogramms. Das JavaDoc nennt die beiden Methoden gegenseitig ausschließend (geprüft am 9. Oktober 2026).

// geplantes Intervall: 10 ms, Werte in Mikrosekunden
Histogram h = new Histogram(3);
h.recordValueWithExpectedInterval(latencyUs, 10_000);

// oder nach dem Lauf, an einem Roh-Histogramm:
Histogram fixed = raw.copyCorrectedForCoordinatedOmission(10_000);

Die Korrektur ist nur so gut wie das Intervall, das Sie übergeben. Sie passt also zu einem Generator, der in gleichmäßigem Takt senden sollte.

Wie gehen k6, Gatling, Locust und JMeter damit um?

k6, Gatling und JMeter können Arbeit nach einem Zeitplan starten, der nicht auf Antworten wartet. Locust taktet jeden Nutzer, kann aber keine zusätzlichen Nutzer starten, um eine Rate zu halten.

k6. In den Arrival-Rate-Executors starten Iterationen unabhängig von der Antwort des Systems, solange ein virtueller Benutzer frei ist. Ist keiner frei, überspringt k6 die Iteration und zählt sie in dropped_iterations, was spät im Test heißen kann, dass das System nachlässt (geprüft am 9. Oktober 2026). Eine verworfene Iteration hat keine Antwortzeit, also lesen Sie diesen Zähler neben den Perzentilen. Auf LoadFocus laufen Arrival-Rate-Szenarien von k6-Skripten mit einer festen Zahl von Nutzern, also als geschlossenes Modell. Führen Sie k6 selbst aus, wenn es gerade um die Ankunftsrate geht.

Gatling. Schritte wie constantUsersPerSec innerhalb von injectOpen starten neue virtuelle Benutzer mit fester Rate, ganz gleich, ob frühere schon fertig sind (geprüft am 9. Oktober 2026).

Locust. constant_throughput passt die Wartezeit jedes Nutzers so an, dass er eine Task höchstens eine bestimmte Zahl von Malen pro Sekunde ausführt. Laut Dokumentation kann die Wartezeit die Rate nur begrenzen und keine neuen Nutzer starten, und die API-Referenz ergänzt, dass nach einer Task, die ihr Intervall überzieht, keine Wartezeit folgt. Eine langsame Antwort verzögert diesen Nutzer also trotzdem (geprüft am 9. Oktober 2026).

JMeter. Eine Thread Group ist ein Pool von Threads in Schleifen, also eine geschlossene Schleife. JMeter 5.5 brachte die experimentelle Open Model Thread Group, die einem Zeitplan wie rate(1/sec) random_arrivals(2 min) folgt und laut Versionshinweisen bei Bedarf Threads erzeugt (geprüft am 9. Oktober 2026).

Beseitigt ein offenes Lastmodell Coordinated Omission?

Es beseitigt die Hauptursache, einen Generator, der vor dem Senden wartet. Zwei Lücken bleiben: Ein Generator, dem Nutzer oder CPU fehlen, fällt trotzdem hinter seinen Zeitplan zurück, und jeder Nutzer in einer mehrstufigen Nutzerreise wartet weiter auf seine eigenen Antworten.

Die erste Lücke zeigt sich als verworfene Iterationen oder als ausgelastete Engine; beides ist ein Grund, mit mehr Reserve neu zu testen. Die zweite steckt in den meisten HTTP-Tests: Das README von wrk2 hält fest, dass Senden ohne Warten nur bei nicht blockierenden Protokollen oder einer Anfrage pro Verbindung funktioniert, und deshalb korrigiert wrk2 stattdessen die Zeitmessung.

FAQ

Von wem stammt der Begriff Coordinated Omission? Gil Tene, der ursprüngliche Autor von HdrHistogram, dessen wrk2-Fork von wrk darauf ausgelegt ist, den Fehler zu vermeiden. Sein Beitrag von 2013 auf der Mailingliste mechanical-sympathy beschreibt ihn als ein Problem, das er so nennt.

Ist Coordinated Omission dasselbe wie ein geschlossenes Lastmodell? Die beiden hängen zusammen. Ein geschlossenes Modell ist eine häufige Ursache, weil jeder virtuelle Benutzer auf seine Antwort wartet, bevor er erneut sendet, und das README von wrk2 findet den Effekt auch in Monitoring-Code.

Sollte man jedes Latenz-Histogramm dafür korrigieren? Nur wenn Sie das Intervall kennen, in dem Anfragen geplant waren, denn HdrHistogram braucht es, um die fehlenden Messwerte aufzufüllen. Wenden Sie auf einen Datensatz eine der beiden Korrekturmethoden an, nie beide.

Weiterlesen

Gatling-Lasttests: das JVM-Tool im Überblick

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Gatling ist ein kostenloses Lasttest-Tool unter Apache-2.0-Lizenz, in dem jeder Test eine als Code geschriebene Simulation ist, die auf der JVM läuft und nach jedem Lauf einen HTML-Bericht liefert. Ein Gatling-Lasttest passt zu Entwicklerteams, die Tests im Repository, offene oder geschlossene Lastmodelle und Assertions wollen, die den Build scheitern lassen. Wer einen grafischen Test-Builder oder viele Protokolle braucht, ist mit JMeter besser bedient, und wer ein einzelnes Binary ohne JVM möchte, mit k6.

Wir haben Gatling für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation, dem Repository und den Release-Seiten von Gatling, geprüft am 9. Oktober 2026; die Einschätzungen sind unsere eigenen.

Thema	Gatling
Lizenz	Apache 2.0, außer den Plugins für gRPC, MQTT und GraphQL
Laufzeit	JVM, 64-Bit-OpenJDK-LTS 11 bis 25
Aktuelle Version	3.16.0 (29. September 2026)
Tests in	Java, Kotlin, Scala, JavaScript, TypeScript
Eingebaute Protokolle	HTTP/1.1, HTTP/2, WebSocket, SSE, JMS
Ergebnisse	Statischer HTML-Bericht pro Lauf
Build und CI	Plugins für Maven, Gradle, sbt und npm
Skalierung	Gatling Enterprise (kommerziell)

Wer entwickelt Gatling, und wird es noch gepflegt?

Gatling Corp, ein französisches Unternehmen, entwickelt Gatling und hält das Urheberrecht daran. Das Projekt wird aktiv gepflegt: 2026 sind bisher drei JVM-Versionen erschienen.

Die Lizenzseite weist Gatling Corp das Urheberrecht zu. Maven Central führt 3.15.0 im Februar, 3.15.1 im Mai und 3.16.0 am 29. September 2026, und das JavaScript-SDK erreichte am 6. Oktober Version 3.16.1. Die Release Notes zu 3.16 bringen GraphQL und gemeinsame Queues zwischen virtuellen Benutzern. Das README nennt das Repository die Community Edition, frei nutzbar auch für kommerzielle Zwecke (geprüft am 9. Oktober 2026).

Was brauchen Sie, um Gatling auszuführen?

Eine 64-Bit-JVM für Java, Kotlin oder Scala, oder Node.js für JavaScript und TypeScript. In beiden Fällen läuft die Simulation selbst auf einer JVM.

Die Installationsseite unterstützt OpenJDK-LTS-Versionen von 11 bis 25 und schließt 32-Bit-JVMs und OpenJ9 aus. Die JavaScript-CLI setzt Node.js 24 oder neuer voraus und lädt ein Gatling-Runtime-Bundle herunter, laut README von gatling-js samt GraalVM (geprüft am 9. Oktober 2026).

Wie ist eine Gatling-Simulation aufgebaut?

Eine Simulation definiert Szenarien, gibt jedem ein Injektionsprofil und hängt eine Protokollkonfiguration an; registriert wird alles in einem einzigen setUp-Aufruf.

In der Simulationsreferenz verkettet ein Szenario Anfragen mit Pausen, Schleifen und Bedingungen. Diese Java-Simulation speichert eine Produkt-ID aus einer Suche, pausiert eine bis drei Sekunden und öffnet das Produkt, während die Ankünfte auf 20 Benutzer pro Sekunde steigen und zehn Minuten lang gehalten werden:

public class ShopSimulation extends Simulation {

  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Die Imports sind weggelassen, und #{id} liest über Gatlings Expression Language den gespeicherten Wert. Gatling vs k6 zeigt eine Simulation in JavaScript.

Sollten Sie Benutzer offen oder geschlossen injizieren?

Offen, für die meisten Websites und APIs, bei denen neue Benutzer weiter eintreffen, egal wie langsam das System wird. Geschlossen passt zu Systemen, die die Parallelität begrenzen, etwa einer Ticket-Warteschlange.

Die Referenz zu Injektionsprofilen trennt die API: injectOpen nimmt Ankunftsraten wie rampUsersPerSec, injectClosed Parallelitätsziele wie constantConcurrentUsers. Die Seite zu Lastmodellen sagt, dass sich die meisten Websites als offene Systeme verhalten und ein Profil die beiden nicht mischen kann (geprüft am 9. Oktober 2026). Unser Beitrag zum offenen vs geschlossenen Lastmodell erklärt die Wahl.

Wie funktionieren Checks, Assertions und der Bericht?

Checks prüfen jede Antwort und können Werte daraus speichern, Assertions bewerten den ganzen Lauf, sobald er endet. Danach schreibt jeder Lauf einen HTML-Bericht.

Ohne expliziten Status-Check prüft Gatling, ob jede HTTP-Antwort 2XX oder 304 ist. Assertions prüfen Antwortzeiten, Anfragezahlen oder Anfragen pro Sekunde, global oder pro Anfrage, und eine einzige gescheiterte Assertion lässt die Simulation scheitern. Der HTML-Bericht zeigt Antwortzeitbereiche und Perzentile, gestartete Benutzer pro Sekunde, gleichzeitige Benutzer und Anfragen pro Sekunde; seine Perzentile im Zeitverlauf zählen nur erfolgreiche Anfragen (geprüft am 9. Oktober 2026).

Wie passt Gatling in Build und CI?

Über das Plugin für Maven, Gradle, sbt oder npm, das in jedem CI-System läuft. Eine gescheiterte Assertion lässt den Build scheitern.

Das Maven-Plugin bindet gatling:test an die Phase integration-test, sodass mvn verify es ausführt, und mit CI=true entfällt die Abfrage der Simulation (der Lauf scheitert dann, wenn das Projekt mehr als eine Simulation enthält und keine benannt ist). Das Gradle-Plugin nutzt gatlingRun, und das sbt-Plugin nimmt nur Scala-Simulationen an. Die fertigen CI-Integrationen von Gatling, etwa die GitHub Action, starten Läufe in Gatling Enterprise (geprüft am 9. Oktober 2026). Unser Leitfaden zu GitHub Actions zeigt den Workflow dazu.

Welche Protokolle unterstützt Gatling?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events und JMS sind ohne Grenzen dabei. gRPC, MQTT und GraphQL sind separate Plugins, die außerhalb von Gatling Enterprise auf 5 Benutzer und 5 Minuten begrenzt sind.

Das README stellt die ersten fünf unter Apache 2.0. Die Setup-Seiten für gRPC, MQTT und GraphQL stellen jedes Plugin unter die Gatling Enterprise Component License: unbegrenzt in Gatling Enterprise, während ein Test mit der Community Edition bei 5 Benutzern oder 5 Minuten stoppt. Diese Lizenz erlaubt die kostenlose Nutzung für höchstens ein Jahr, nur für interne Tests der eigenen Webanwendungen; sie endet, sobald ein Limit erreicht ist, und Gatling kann die Limits ändern. GraphQL setzt 3.16.0 oder neuer voraus. Laut Release Notes und README unterstützt das JavaScript-SDK GraphQL noch nicht, obwohl die Setup-Seite bereits ein npm-Paket nennt; prüfen Sie das also, bevor Sie einen GraphQL-Test in JavaScript planen (geprüft am 9. Oktober 2026). Unser Leitfaden zum Lasttest einer GraphQL-API umgeht die Grenze mit einfachen HTTP-Anfragen.

Was bringt Gatling Enterprise zusätzlich?

Gatling Enterprise ist die kommerzielle Edition auf derselben Engine. Sie erzeugt Last aus verwalteter oder privater Infrastruktur, was die freie Edition nicht tut.

Laut README führt Enterprise Tests auf verwalteten Lastgeneratoren oder in Ihren eigenen Konten bei AWS, Azure, GCP oder Kubernetes aus und ergänzt Live-Dashboards, Trends, Teams mit SSO und CI/CD-Integrationen. Die FAQ sagt, dass die Community Edition keine verteilten Tests unterstützt und dass Simulationen unverändert zu Enterprise wechseln können (geprüft am 9. Oktober 2026).

LoadFocus, der Herausgeber dieser Website, führt keine Gatling-Simulationen aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus, und zwar aus 25 Cloud-Regionen. Für Gatling führt der Weg zu mehr Maschinen also über Gatling Enterprise.

Was kann Gatling gut, und wo liegen seine Grenzen?

Stark ist Gatling bei Tests als Code, den man im Review prüfen kann, bei Lastmodellen und bei Berichten ohne Einrichtung. Schwächer ist es bei Protokollen jenseits von Web und Messaging und bei kostenloser Skalierung über eine Maschine hinaus.

Das README hebt die Engine hervor: nicht blockierend, auf Netty gebaut, jeder virtuelle Benutzer eine leichtgewichtige Nachricht. Grenzen, die die Dokumentation selbst nennt (geprüft am 9. Oktober 2026):

Gatling ist kein Browser: Laut der Seite zum HTTP-Protokoll führt es kein JavaScript aus.
Das JavaScript-SDK kennt kein JMS und kann keine npm-Bibliotheken nutzen, die native Binaries oder Node.js-APIs brauchen.
HTTP-Caching ist standardmäßig aktiv, was die Zahl der Anfragen senken kann.
Das Format von simulation.log ist nicht dokumentiert und kann sich jederzeit ändern.

Wann sollten Sie stattdessen k6, JMeter oder Locust wählen?

Wählen Sie ein anderes Tool, wenn dessen Sprache, Protokolle oder kostenloser Weg zur Skalierung besser zu Ihrem Team passen.

Unser Überblick über Open-Source-Lasttest-Tools stellt Gatling neben fünf weitere.

Wählen Sie stattdessen k6, wenn Sie in der CI ein einzelnes Binary ohne JVM, Thresholds, die einen scheiternden Lauf früh stoppen können, oder gRPC als eingebautes Protokoll wollen (geprüft am 9. Oktober 2026). Gatling vs k6 vergleicht die beiden.

Wählen Sie stattdessen JMeter, wenn Ihre Tester Tests in einer GUI bauen oder Sie JDBC, LDAP oder FTP aus dem Kern brauchen (geprüft am 9. Oktober 2026). LoadFocus führt vorhandene JMeter-Testpläne aus, aus 25 Cloud-Regionen, und Gatling vs JMeter geht tiefer.

Wählen Sie stattdessen Locust, wenn Ihr Team Python schreibt und einen verteilten Modus im kostenlosen Tool möchte (geprüft am 9. Oktober 2026). Unser Locust-Review beschreibt es.

FAQ

Darf man Gatling kostenlos kommerziell nutzen? Ja. Die Community Edition steht unter Apache 2.0. Die Plugins für gRPC, MQTT und GraphQL haben eine eigene Lizenz und sind außerhalb von Gatling Enterprise auf 5 Benutzer und 5 Minuten begrenzt.

Braucht man Java, um Gatling zu nutzen? Für Java, Kotlin oder Scala ja: ein 64-Bit-OpenJDK-LTS von 11 bis 25. Das JavaScript-SDK braucht Node.js 24 oder neuer, und seine CLI lädt die JVM-Laufzeit selbst herunter.

Kann LoadFocus Gatling-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um eine Gatling-Simulation auf mehrere Maschinen zu verteilen, nutzen Sie Gatling Enterprise.

Weiterlesen

Gatling vs JMeter: Tests als Code oder GUI-Testplan?

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Gatling und Apache JMeter sind beide kostenlose Open-Source-Lasttest-Tools, die auf der JVM laufen, und die Wahl hängt vor allem davon ab, wie Ihr Team Tests bauen möchte. Nehmen Sie Gatling, wenn Sie Tests als Code in Java, Kotlin, Scala, JavaScript oder TypeScript, offene Injektionsprofile und nach jedem Lauf einen HTML-Bericht wollen. Nehmen Sie JMeter, wenn Sie Protokolle wie JDBC, LDAP, FTP oder Mail ohne Zusatzaufwand brauchen, Tests lieber in einer GUI zusammenstellen oder bereits .jmx-Testpläne besitzen.

Die Fakten in diesem Vergleich Gatling vs JMeter stammen aus der Dokumentation und den Repositories der beiden Projekte, geprüft am 9. Oktober 2026.

	Gatling	Apache JMeter
Lizenz	Apache 2.0; gRPC, MQTT und GraphQL unter einer eigenen Komponentenlizenz (Repository)	Apache 2.0 (Repository)
Laufzeit	JVM, OpenJDK LTS 11 bis 25 (Version 3.16.0)	JVM, Java 8 oder neuer (Version 5.6.3)
Tests geschrieben als	Code in Java, Kotlin, Scala, JavaScript oder TypeScript	Testpläne, in einer GUI gebaut und als XML-Dateien (`.jmx`) gespeichert
Eingebaute Protokolle	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, Mail, TCP, Shell-Befehle, Java-Objekte
Recorder	HTTP-Proxy oder Konverter für HAR-Dateien	HTTP(S) Test Script Recorder (Proxy)
Lastmodell	Offene oder geschlossene Injektionsprofile	Thread Groups; eine experimentelle Open Model Thread Group
Skalierung	Ein Rechner; verteilte Läufe brauchen Gatling Enterprise	Eingebauter Remote-Modus, ein Client steuert viele Server
CI und Headless-Läufe	Plugins für Maven, Gradle, sbt und npm; eine verfehlte Assertion lässt den Lauf scheitern	CLI-Modus (`jmeter -n`); Maven-, Gradle- und Jenkins-Plugins von Drittanbietern
Berichte	HTML-Bericht nach jedem Lauf	HTML-Dashboard; Live-Ergebnisse über einen Backend Listener

Was ist der Unterschied zwischen Gatling und JMeter?

In Gatling ist ein Test ein Programm in einem Build-Projekt. In JMeter ist ein Test ein Baum aus Elementen, den Sie in einer Desktop-GUI zusammenstellen und als XML-Datei speichern, und daraus ergeben sich die meisten anderen Unterschiede.

Das README von Gatling nennt Tests Simulationen und legt sie wie Anwendungscode in Ihr Repository; ausgeführt werden sie über ein Plugin für Maven, Gradle, sbt oder npm. Das SDK für JavaScript und TypeScript wird über npm installiert und lädt seine eigene GraalVM-Laufzeit herunter.

Ein JMeter-Plan enthält eine Thread Group für die Benutzer, Sampler für die Anfragen sowie Assertions und Listener für die Ergebnisse. JMeter 5.6.3, die aktuelle Version auf der Download-Seite, braucht Java 8 oder neuer. Das README im Entwicklungszweig von JMeter verlangt bereits Java 17 (geprüft am 10. Oktober 2026). Unter der Haube führt JMeter jeden virtuellen Benutzer als Java-Thread aus, während das README von Gatling virtuelle Benutzer als leichtgewichtige Nachrichten auf einer nicht blockierenden Engine auf Basis von Netty beschreibt.

Wie schreibt man in beiden Tools einen Test?

In Gatling schreiben Sie eine Simulationsklasse, die ein Szenario, ein Injektionsprofil und Assertions festlegt. In JMeter fügen Sie in der GUI eine Thread Group und Sampler hinzu, speichern den Plan und starten ihn dann von der Kommandozeile.

Eine Java-Simulation nach dem Vorbild des Tutorials zur ersten Simulation von Gatling: Neue Benutzer kommen anfangs mit einem pro Sekunde an, steigen innerhalb einer Minute auf zehn pro Sekunde und bleiben dann fünf Minuten auf diesem Niveau. Der Lauf scheitert, wenn das 95. Perzentil über 500 ms steigt oder mehr als 1 % der Anfragen fehlschlagen:

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1);

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Starten Sie sie mit ./mvnw gatling:test; eine JavaScript- oder TypeScript-Simulation starten Sie mit npx gatling run.

In JMeter ist derselbe Test eine Thread Group mit einem HTTP-Request-Sampler, und eine Duration Assertion kann jede zu langsame Antwort als fehlgeschlagen markieren. Der Einstiegsleitfaden baut den Plan im GUI-Modus und führt ihn im CLI-Modus aus; -e -o erzeugt am Ende den HTML-Bericht:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Beide Tools können einen ersten Entwurf im Browser aufzeichnen. Der Recorder von Gatling arbeitet als HTTP-Proxy oder wandelt eine HAR-Datei in eine Simulation um, und der HTTP(S) Test Script Recorder von JMeter zeichnet Browser-Traffic in einen Plan auf (geprüft am 9. Oktober 2026). Die Dokumentation von Gatling führt diesen Recorder inzwischen als Legacy, und das neuere Gatling Studio verlangt zum Anmelden ein Enterprise-Konto (geprüft am 10. Oktober 2026).

Welche Protokolle kann jedes Tool testen?

JMeter deckt von Haus aus mehr Protokolle ab. Gatling bringt die wichtigsten Webprotokolle plus JMS mit und überlässt den Großteil des Rests eigenen Komponenten oder Community-Plugins.

Das README von JMeter nennt jedes Protokoll aus der Tabelle oben, Mail eingeschlossen. JDBC und JMS brauchen Treiber-JARs von Ihrem Datenbank- oder JMS-Anbieter, und der Plugins Manager installiert Community-Plugins direkt aus der GUI.

Laut dem README von Gatling sind gRPC, MQTT und GraphQL eigene Komponenten unter der Gatling Enterprise Component License, ohne Enterprise begrenzt auf fünf gleichzeitige Benutzer und Tests von fünf Minuten. Kafka, AMQP, SFTP, FTP und JDBC kommen aus Drittanbieter-Plugins für Gatling 3.13, die Gatling nicht selbst pflegt (geprüft am 9. Oktober 2026).

Wie modellieren Gatling und JMeter Last?

Gatling lässt Sie schon im Skript zwischen einem offenen und einem geschlossenen Modell wählen. Die klassische Thread Group von JMeter ist ein geschlossener Pool von Benutzern, und für ankunftsbasierte Last brauchen Sie die neuere Open Model Thread Group.

In Gatling nimmt injectOpen Ankunftsraten wie constantUsersPerSec und rampUsersPerSec entgegen, injectClosed dagegen Zielwerte für die Parallelität wie constantConcurrentUsers. JMeter 5.5 hat die Open Model Thread Group eingeführt, die die Referenz weiterhin als experimentell kennzeichnet (geprüft am 9. Oktober 2026). Unser Leitfaden zum offenen vs geschlossenen Lastmodell erklärt, warum diese Wahl wichtig ist.

Wie verteilt man einen Test auf mehrere Rechner?

JMeter hat einen verteilten Modus eingebaut. Die Open-Source-Edition von Gatling erzeugt Last von einem Rechner aus, und die Dokumentation nennt ein Gatling-Enterprise-Konto als Voraussetzung für verteilte Läufe.

Im Remote-Modus steuert ein JMeter-Client beliebig viele Server. Jeder Server führt den ganzen Plan aus, 1.000 Threads auf sechs Servern ergeben also 6.000 Threads. Alle Knoten sollten dieselbe JMeter- und Java-Version verwenden, RMI braucht einen Keystore, sofern SSL nicht deaktiviert ist, und Datendateien müssen auf jeden Server kopiert werden.

Für JMeter-Testpläne gibt es einen dritten Weg. LoadFocus, der Herausgeber dieser Website, führt bestehende JMeter-Testpläne unverändert aus 25 Cloud-Regionen aus, ohne dass Sie Remote-Server einrichten müssen. LoadFocus führt keine Gatling-Simulationen aus.

Wie passen sie in die CI, und welche Berichte bekommen Sie?

Beide laufen headless. Die Assertions von Gatling können den Build direkt scheitern lassen, während die Assertions von JMeter einzelne Samples markieren und die CI-Anbindung aus Bibliotheken von Drittanbietern kommt.

Assertions in Gatling werden nach dem Lauf geprüft, und eine einzige fehlgeschlagene Assertion lässt die Simulation und damit den Build-Task scheitern. Der HTML-Bericht zeigt Perzentile der Antwortzeit, gestartete Benutzer pro Sekunde, gleichzeitige Benutzer und Anfragen pro Sekunde im Zeitverlauf.

Der CLI-Modus von JMeter kennt keine Pass/Fail-Option, daher scheitert ein Build an einem verfehlten Ziel nur über die im README genannten Bibliotheken für Maven, Gradle und Jenkins oder über eine eigene Prüfung. Das Dashboard bringt eine APDEX-Tabelle, eine Statistiktabelle mit drei konfigurierbaren Perzentilen und Fehlerübersichten mit, und ein Backend Listener streamt Live-Ergebnisse nach InfluxDB oder Graphite.

Welches Tool sollten Sie wählen?

Wählen Sie Gatling, wenn Ihr Team Java, Kotlin, Scala oder TypeScript schreibt und Lasttests wie den übrigen Code reviewen möchte. Wählen Sie stattdessen JMeter, wenn Sie Protokolle jenseits des Webs brauchen, wenn Ihre Tester eine GUI bevorzugen oder wenn Sie bereits .jmx-Pläne haben.

Gatling passt zu Teams, die Traffic als Ankunftsraten beschreiben und Pass/Fail-Regeln direkt neben dem Szenario sowie einen lesbaren Bericht ohne Zusatzaufwand wollen.

JMeter ist die bessere Wahl für Tests von JDBC, LDAP, FTP oder Mail, für Tester, die einen aufgezeichneten Ablauf visuell verfeinern, und für verteilte Läufe auf eigenen Servern ohne kommerzielle Lizenz. Ein Unternehmen, das JMeter bereits nutzt, behält außerdem seine Pläne, Plugins und sein Know-how.

FAQ

Ist Gatling schneller als JMeter? Das haben wir nicht selbst gemessen, deshalb nennen wir keinen Sieger. Fair vergleichen lässt sich das nur mit demselben Szenario in beiden Tools auf Ihrer eigenen Hardware.

Kann Gatling .jmx-Dateien von JMeter ausführen? Nicht direkt. Gatling führt Simulationen aus, die mit seinen SDKs geschrieben sind, ein JMeter-Plan muss also neu geschrieben werden. Das README von Gatling nennt KI-Erweiterungen, die JMeter-Testpläne umwandeln, und diese brauchen einen API-Token für Gatling Enterprise.

Kann LoadFocus Gatling-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um eine Gatling-Simulation auf mehrere Rechner zu verteilen, nutzen Sie Gatling Enterprise.

Weiterlesen

Gatling vs k6: JVM-Simulationen oder ein Go-Binary?

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Gatling und k6 sind beide Open-Source-Tools, die Lasttests als Code in Ihrem Repository halten, und mit beiden lässt sich eine HTTP-API gut unter Last testen. Nehmen Sie Gatling, wenn Ihr Team in Java, Kotlin oder Scala arbeitet oder nach jedem Lauf ohne Zusatzaufwand einen HTML-Bericht haben möchte. Nehmen Sie k6, wenn Sie ein einzelnes Go-Binary ohne JVM, gRPC und Browsertests ab Werk sowie Schwellenwerte wollen, die einen scheiternden Lauf vorzeitig stoppen können.

Die Fakten in diesem Vergleich Gatling vs k6 stammen aus der Dokumentation und den Repositories der beiden Projekte, geprüft am 9. Oktober 2026.

	Gatling	k6
Lizenz	Apache 2.0; gRPC, MQTT und GraphQL unter einer eigenen Komponentenlizenz (Repository)	AGPL-3.0 (Repository)
Laufzeit	JVM; das Java-SDK braucht OpenJDK LTS 11 bis 25 (Version 3.16.0)	Ein Go-Binary mit eingebetteter JavaScript-Engine (Version v2.3.0)
Testskripte	Java, Kotlin, Scala, JavaScript oder TypeScript	JavaScript, oder TypeScript ohne Typprüfung
Kernprotokolle	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP/1.1, HTTP/2, WebSockets, gRPC
Lastmodell	Offene oder geschlossene Injektionsprofile	Sechs Executors, davon zwei mit Ankunftsrate (offenes Modell)
Pass/Fail	Assertions, geprüft nach dem Lauf	Schwellenwerte (`thresholds`), die einen Lauf auch vorzeitig abbrechen können
Berichte	HTML-Bericht nach jedem Lauf	Zusammenfassung am Testende; Web-Dashboard mit HTML-Export
Browsertests	Nicht eingebaut; der Recorder macht aus Browser-Traffic Code	Eingebautes Browser-Modul (steuert einen Chromium-basierten Browser)
Skalierung	Gatling Enterprise	k6-operator auf Kubernetes oder Grafana Cloud k6

Was ist der Unterschied zwischen Gatling und k6?

Der größte Unterschied ist die Laufzeit. Gatling läuft auf der JVM, und Sie schreiben Tests mit einem seiner SDKs, während k6 ein einzelnes kompiliertes Go-Programm ist, das JavaScript ausführt.

Das README von Gatling nennt ein Java-SDK für Java, Kotlin und Scala, das über ein Plugin für Maven, Gradle oder sbt läuft. Das SDK für JavaScript und TypeScript wird über npm installiert, und sein Kommandozeilen-Tool lädt GraalVM herunter, sodass auch eine JavaScript-Simulation auf einer JVM läuft.

k6 wird als Paket oder eigenständiges Binary installiert und braucht keine weitere Laufzeit. Es führt auch .ts-Dateien direkt aus, wobei die TypeScript-Unterstützung die Typen entfernt, ohne sie zu prüfen (geprüft am 9. Oktober 2026).

Wie schreibt man denselben Test in beiden Tools?

Beide Tools können denselben Test in JavaScript ausdrücken. Gatling nennt ihn eine Simulation und beschreibt die Last als Injektionsprofil, k6 nennt ihn ein Skript und beschreibt die Last als Szenario mit einem Executor.

Hier ein Test, bei dem fünf Minuten lang jede Sekunde zehn neue Benutzer ankommen und der Lauf scheitert, wenn das 95. Perzentil über 500 ms steigt oder mehr als 1 % der Anfragen fehlschlagen. Im JavaScript-SDK von Gatling, nach dem Vorbild des Tutorials zur ersten Simulation:

import {
  constantUsersPerSec, global, scenario, simulation,
} from "@gatling.io/core";
import { http } from "@gatling.io/http";

export default simulation((setUp) => {
  const api = http.baseUrl("https://staging.example.com");

  const users = scenario("API users")
    .exec(http("list users").get("/api/users"));

  setUp(users.injectOpen(constantUsersPerSec(10).during(300)))
    .protocols(api)
    .assertions(
      global().responseTime().percentile(95).lt(500),
      global().failedRequests().percent().lt(1),
    );
});

Derselbe Test in k6, mit dem Executor constant-arrival-rate:

import http from "k6/http";

export const options = {
  scenarios: {
    api_users: {
      executor: "constant-arrival-rate",
      rate: 10,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 50,
    },
  },
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
}

Gestartet werden sie mit npx gatling run und k6 run script.js.

Wie modellieren Gatling und k6 Last?

Beide unterstützen offene und geschlossene Lastmodelle. In Gatling fällt die Wahl über die Injektionsmethode, die Sie aufrufen, in k6 über den Executor, den Sie auswählen.

In Gatling nimmt injectOpen Ankunftsraten wie constantUsersPerSec entgegen, injectClosed dagegen Zielwerte für die Parallelität wie constantConcurrentUsers. k6 hat sechs Executors: Die beiden mit Ankunftsrate folgen dem offenen Modell, die anderen vier dem geschlossenen, bei dem ein virtueller Benutzer seine nächste Iteration erst startet, wenn die letzte fertig ist.

Ein Arrival-Rate-Szenario in k6 startet Iterationen aus einem Pool vorab angelegter virtueller Benutzer, und wenn dieser Pool erschöpft ist, überspringt k6 Iterationen und zählt sie als verworfene Iterationen (dropped_iterations) (geprüft am 9. Oktober 2026). Unser Leitfaden zum offenen vs geschlossenen Lastmodell erklärt, wann welches Modell passt.

Wie entscheiden Gatling und k6, ob ein Test bestanden ist?

Beide machen aus Performance-Zielen ein Ergebnis, mit dem eine CI-Pipeline arbeiten kann: bestanden oder nicht bestanden. Gatling prüft seine Ziele nach dem Ende des Laufs, und k6 kann einen Lauf zusätzlich stoppen, sobald ein Ziel verfehlt ist.

Assertions in Gatling werden nach der Simulation ausgewertet, und eine einzige fehlgeschlagene Assertion lässt die Simulation und den Build scheitern. Schwellenwerte in k6 beenden einen gescheiterten Lauf mit einem Exit-Code ungleich null, und ein Schwellenwert mit abortOnFail stoppt den Test in dem Moment, in dem er verfehlt wird (geprüft am 9. Oktober 2026).

Welche Protokolle und Browsertests decken die Tools ab?

Beide beherrschen HTTP und WebSockets ab Werk. Gatling bringt zusätzlich Server-Sent Events und JMS mit, k6 gRPC und echte Browser-Sitzungen.

Laut README von Gatling sind gRPC, MQTT und GraphQL eigene Komponenten unter der Gatling Enterprise Component License, ohne Enterprise begrenzt auf fünf gleichzeitige Benutzer und fünf Minuten Testdauer. k6 nennt HTTP/1.1, HTTP/2, WebSockets und gRPC als eingebaute Protokolle, weitere kommen über xk6-Erweiterungen wie Kafka und Redis hinzu.

Für Browsertests hat k6 ein Browser-Modul, das einen Chromium-basierten Browser steuert und Frontend-Metriken sammelt. Die Dokumentation von Gatling beschreibt keine Browser-Engine: Der Recorder macht aus einer Browser-Sitzung oder einer HAR-Datei eine Simulation auf HTTP-Ebene (geprüft am 9. Oktober 2026).

Wie fährt man einen Test, der mehr Last braucht, als ein Rechner erzeugen kann?

Die Open-Source-Edition von Gatling erzeugt Last von einem Rechner aus, und verteilte Läufe brauchen Gatling Enterprise. k6 kann einen Test mit dem quelloffenen k6-operator auf einen Kubernetes-Cluster verteilen oder ihn in Grafana Cloud k6 ausführen.

Die Installationsanleitung von Gatling nennt ein Enterprise-Konto als Voraussetzung für verteilte Läufe, die auf verwalteten Lastgeneratoren oder an privaten Standorten in Ihrem eigenen AWS-, Azure-, GCP- oder Kubernetes-Konto laufen. Der k6-operator teilt einen Test auf mehrere k6-Instanzen in einem Cluster auf (geprüft am 9. Oktober 2026).

Für k6-Skripte gibt es einen dritten Weg. LoadFocus, der Herausgeber dieser Website, führt k6-Skripte auf seiner eigenen Cloud-Infrastruktur aus 25 Regionen aus, wobei Benutzerzahl und Dauer aus den Einstellungen des Tests kommen. Sein Skript-Validator weist darauf hin, dass Arrival-Rate-Szenarien dort mit einer festen Zahl von Benutzern laufen; ein Skript mit offenem Modell wie das obige hält auf LoadFocus also seine Ankunftsrate nicht. LoadFocus führt keine Gatling-Simulationen aus, für Gatling bleibt also Gatling Enterprise der Weg zu mehr Rechnern.

Welche Berichte bekommen Sie?

Gatling schreibt nach jedem Lauf ohne Einrichtung einen HTML-Bericht. k6 gibt eine Zusammenfassung im Terminal aus und kann über sein eingebautes Web-Dashboard einen HTML-Bericht erzeugen.

Der HTML-Bericht von Gatling zeigt Perzentile der Antwortzeit, gestartete Benutzer pro Sekunde und Anfragen pro Sekunde im Zeitverlauf. k6 gibt eine Zusammenfassung am Testende aus, und sein Web-Dashboard zeigt Live-Diagramme und exportiert einen eigenständigen HTML-Bericht, wenn Sie K6_WEB_DASHBOARD_EXPORT setzen.

Welches Tool sollten Sie wählen?

Gatling passt zu Teams auf der JVM, k6 zu Teams, die ein einzelnes Binary und JavaScript wollen. Protokolle, Browsertests und Skalierung entscheiden die meisten übrigen Fälle.

Wählen Sie Gatling statt k6, wenn Ihr Team auf der JVM zu Hause ist und Tests in Java, Kotlin oder Scala mit Maven, Gradle oder sbt neben dem Anwendungscode bauen möchte, wenn Sie JMS oder Server-Sent Events brauchen oder wenn Sie nach jedem Lauf ohne Einrichtung einen HTML-Bericht wollen.

Wählen Sie k6 statt Gatling, wenn Sie ein einzelnes Binary in der CI ohne zu installierende JVM wollen, wenn Ihre Tests gRPC oder echte Browser-Sitzungen brauchen, wenn Schwellenwerte einen scheiternden Lauf vorzeitig stoppen sollen oder wenn Sie mit einem quelloffenen Operator auf Kubernetes skalieren möchten.

FAQ

Ist Gatling schneller als k6? Das haben wir nicht selbst gemessen, deshalb nennen wir keinen Sieger. Fair vergleichen lässt sich das nur mit demselben Szenario in beiden Tools auf Ihrer eigenen Hardware.

Kann Gatling k6-Skripte ausführen? Nicht laut der Dokumentation von Gatling, die keinen Weg beschreibt, k6-Skripte auszuführen. Die beiden SDKs haben unterschiedliche APIs, und die Konverter von Gatling decken JMeter und LoadRunner ab. Ein k6-Skript muss also als Gatling-Simulation neu geschrieben werden, auch mit dem JavaScript-SDK.

Kann LoadFocus Gatling-Tests ausführen? Nein. LoadFocus führt k6-Skripte und JMeter-Testpläne aus. Um eine Gatling-Simulation auf mehrere Rechner zu verteilen, nutzen Sie Gatling Enterprise.

Weiterlesen

GraphQL-API-Lasttest: ein praktischer Leitfaden

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Für einen GraphQL-API-Lasttest skripten Sie die Operationen, die Ihre Clients tatsächlich senden, geben jeder im Testtool einen eigenen Namen und mischen sie mit wechselnden Variablen im selben Verhältnis wie in der Produktion. Prüfen Sie jeden Antwort-Body auf ein errors-Array, denn ein GraphQL-Server antwortet meist mit HTTP 200, auch wenn ein Teil der Operation fehlgeschlagen ist. Steigern Sie dann die Last und beurteilen Sie jede Operation nach ihren eigenen Perzentilen.

Quellen: graphql.org, der Entwurf der GraphQL-over-HTTP-Spezifikation und die Dokumentation der jeweiligen Tools, alles geprüft am 9. Oktober 2026.

Tool	Operation benennen mit	Antwort mit `errors` scheitern lassen	Variablen einspeisen aus
k6	`tags: { name: "..." }`	Ein `check()` auf den geparsten Body	`SharedArray`
JMeter	Dem Namen des Samplers	JSON Assertion auf `$.errors`, invertiert	CSV Data Set Config
Gatling	`http("...")` oder dem GraphQL-Plugin	`jsonPath("$.errors").notExists()`	Feedern
Artillery	Einem `name` an der Anfrage	`notHasProperty: "errors"`	`config.payload`

Warum braucht eine GraphQL-API einen anderen Lasttest?

Weil jede Operation an dieselbe URL geht und die Arbeit dahinter von der Abfrage und ihren Variablen abhängt. Ein nach URL gruppierter Bericht wirft einen billigen Lookup und eine teure Suche in denselben Topf.

Laut dem Leitfaden Serving over HTTP von graphql.org arbeitet ein GraphQL-Server über einen einzigen Endpunkt, meist /graphql. Operationen kommen dort per POST an, mit einem JSON-Body aus query, einem optionalen operationName und variables.

Wie erhalten Sie Ergebnisse pro Operation?

Benennen Sie jede Anfrage nach ihrer GraphQL-Operation und lassen Sie das Tool seine Statistiken nach diesem Namen gruppieren. Jedes Tool hat dafür einen eigenen Schalter (geprüft am 9. Oktober 2026).

k6: Der Leitfaden zu Tags und Gruppen empfiehlt tags.name, um einer Anfrage einen sprechenden Namen zu geben, und Thresholds können auf einen einzelnen Tag zielen, etwa http_req_duration{name:GetProduct}.
JMeter: Der Aggregate Report legt für jede unterschiedlich benannte Anfrage eine eigene Zeile an. Seit JMeter 5.4 hat der Sampler GraphQL HTTP Request eigene Felder für Query, Variables und Operation Name.
Gatling: Der Name der Anfrage ist der Schlüssel für die Statistiken, und das GraphQL-Plugin benennt Anfragen nach der Operation, etwa query GetUser.
Artillery: Das Plugin metrics-by-endpoint berichtet pro URL und ergänzt den Eintrag um den name einer Anfrage, sodass benannte Operationen getrennt erscheinen; useOnlyRequestNames: true lässt die URL weg und behält nur den Namen.

Welche Operationen sollte der Test senden?

Die, die auch die Produktion erhält, im selben Verhältnis. Entnehmen Sie die Häufigkeit jeder Operation Ihren Server-Logs oder Ihrem GraphQL-Monitoring und machen Sie daraus einen gewichteten Mix aus Lesezugriffen und Mutationen.

Verwenden Sie die Dokumente, die Ihre Clients ausliefern, in ihrer echten Tiefe, statt einer vereinfachten Abfrage. Speisen Sie Variablen aus einer Datei ein, damit der Server viele verschiedene Datensätze nachschlägt, statt ein einziges Ergebnis aus dem Cache zu liefern. Halten Sie auch die Zahl unterschiedlicher Operationen realistisch: Apollos Technote zum Lasttest von GraphQL, ein Herstellerdokument, erklärt, dass jede neue Operation vor der Ausführung geparst und validiert wird, und rät davon ab, weit mehr eindeutige Operationen zu erzeugen, als echte Clients senden.

Mutationen verändern Daten, führen Sie sie also dort aus, wo sich die Daten zurücksetzen lassen. Die Schritt-für-Schritt-Anleitung zum Lasttest behandelt Ziele und Ramp-up.

Warum kann eine Antwort mit HTTP 200 trotzdem ein Fehler sein?

Weil GraphQL Fehler im Antwort-Body meldet. Eine Anfrage kann Status 200 mit einem errors-Array und unvollständigen Daten liefern, und eine reine Statusprüfung lässt sie durch.

Die Seite Response auf graphql.org erklärt, dass die Ausführung weiterläuft, wenn ein Resolver fehlschlägt, und die Antwort dann data neben errors enthält. Der HTTP-Leitfaden ergänzt, dass eine solche Antwort trotzdem einen 2xx-Status erhalten soll, weil HTTP keinen Code für einen Teilerfolg kennt, und dass manche älteren Server sogar bei Validierungsfehlern mit 2xx antworten. Der Entwurf GraphQL over HTTP schlägt für Teilerfolge mit dem neueren Medientyp application/graphql-response+json einen eigenen Status 294 vor.

Im Lasttest schadet das doppelt. Fehler werden nicht gezählt, und Anfragen, die schnell scheitern, etwa an einem Tiefenlimit abgelehnte Operationen, drücken die Antwortzeiten nach unten.

Wie prüfen Sie das errors-Array in jedem Tool?

Parsen Sie den JSON-Body und lassen Sie die Anfrage scheitern, wenn errors vorhanden ist. Jedes Tool bringt dafür ein eingebautes Mittel mit.

In k6 erledigt das ein Check auf den geparsten Body, und ein Threshold auf die Metrik checks lässt den Lauf scheitern, denn Checks allein ändern den Exit-Code von k6 nicht:

import http from "k6/http";
import { check, sleep } from "k6";
import { SharedArray } from "k6/data";

const URL = "https://staging.example.com/graphql";
const ids = new SharedArray("ids", () =>
  JSON.parse(open("./product-ids.json")));
const QUERY = `query GetProduct($id: ID!) {
  product(id: $id) { id name price }
}`;

export const options = {
  vus: 20,
  duration: "5m",
  thresholds: {
    checks: ["rate>0.99"],
    "http_req_duration{name:GetProduct}": ["p(95)<400"],
  },
};

function parse(res) {
  try { return res.json(); } catch (e) { return null; }
}

export default function () {
  const id = ids[Math.floor(Math.random() * ids.length)];
  const payload = JSON.stringify({
    query: QUERY,
    operationName: "GetProduct",
    variables: { id: id },
  });
  const res = http.post(URL, payload, {
    headers: { "Content-Type": "application/json" },
    tags: { name: "GetProduct" },
  });
  const body = parse(res);
  check(res, {
    "status is 2xx": (r) => r.status >= 200 && r.status < 300,
    "no GraphQL errors": () => body !== null && !body.errors,
  });
  sleep(1);
}

SharedArray lädt die IDs einmal für alle virtuellen Benutzer. Das try verhindert, dass ein Body, der kein JSON ist, etwa die Fehlerseite eines Proxys, die Iteration abbricht.

In JMeter fügen Sie eine JSON Assertion mit dem Pfad $.errors hinzu und setzen den Haken bei "Invert assertion", damit das Sample scheitert, sobald der Pfad existiert. Ein JSON Extractor übernimmt IDs in Variablen für die nächste Operation.

In Gatling ergänzen Sie .check(jsonPath("$.errors").notExists()), beides aus der Check-Referenz. Das GraphQL-Plugin prüft Status und Fehler standardmäßig, doch seine Setup-Seite begrenzt Läufe mit der Community Edition auf 5 Benutzer und 5 Minuten (geprüft am 9. Oktober 2026). Für größere Tests ohne Gatling Enterprise nehmen Sie normale HTTP-Anfragen mit diesem Check.

In Artillery bietet das expect-Plugin notHasProperty: "errors", und reportFailuresAsErrors: true bringt fehlgeschlagene Erwartungen in den Bericht. Ein capture mit einem json-Pfad trägt einen Wert in die nächste Anfrage.

Worauf sollten Sie neben den Antwortzeiten achten?

Auf Caching, Persisted Queries und die Datenbanklast pro Anfrage. Jedes davon kann einen Test schneller oder langsamer als die Produktion machen, aus Gründen, die mit der Kapazität nichts zu tun haben.

Der Performance-Leitfaden von graphql.org hält fest, dass per GET gesendete Abfragen HTTP- und CDN-Caching nutzen können und dass Persisted Queries einen Client statt des vollständigen Dokuments einen Hash senden lassen. Machen Ihre Clients das, sollte der Test es auch tun. Machen sie es nicht, misst ein Test, der eine Abfrage mit immer denselben Variablen wiederholt, einen Cache, den echter Traffic verfehlt. Apollos Technote ergänzt, dass Apollo Server, Gateway und der GraphOS Router Automatic Persisted Queries standardmäßig aktivieren.

Derselbe Leitfaden beschreibt das N+1-Problem: Eine Liste, deren Resolver jedes Element einzeln lädt, macht aus einer Anfrage viele Datenbankabfragen, meist behoben durch Batching mit einem Tool wie DataLoader. Beobachten Sie Datenbankabfragen pro Sekunde neben Anfragen pro Sekunde; steigen sie unter wachsender Last viel schneller, ist ein Resolver der Verdächtige. Auch Tiefenlimits, Komplexitätslimits und Rate Limiting können während eines Tests greifen.

Woher sollte die Last kommen?

Von einem Rechner, solange Sie das Skript bauen und einen Smoke-Test fahren, dann aus der Cloud, wenn Sie mehr Last oder Traffic aus mehreren Regionen brauchen.

LoadFocus führt k6-Skripte aus 25 Cloud-Regionen aus. Dort kommen die Zahl der Benutzer und die Dauer aus den Testeinstellungen statt aus den options des Skripts, und Arrival-Rate-Szenarien laufen mit einer festen Zahl von Benutzern statt mit einer festen Anfragerate, der Unterschied, den der Artikel zum offenen und geschlossenen Lastmodell erklärt. LoadFocus veröffentlicht außerdem eine Vorlage für GraphQL-Endpunkte mit komplexen Abfragen (auf Englisch).

FAQ

Sollte ein GraphQL-Lasttest Abfragen per GET oder per POST senden? So, wie es Ihre Clients tun. graphql.org erlaubt GET nur für Abfragen, Mutationen müssen POST verwenden. Sendet die Produktion Persisted Queries per GET über ein CDN, testen Sie auch diesen Weg.

Kann dasselbe Skript auch GraphQL-Subscriptions unter Last setzen? Meist nicht. graphql.org weist darauf hin, dass Subscriptions langlebig sind und oft über WebSockets oder Server-Sent Events laufen, sie brauchen also ein eigenes Szenario in einem Tool, das dieses Transportprotokoll unterstützt.

Sollte eine Teilantwort als fehlgeschlagene Anfrage zählen? In den meisten Tests ja, denn der Client hat für einen Teil seiner Anfrage einen Fehler bekommen. Sind manche Fehler erwartet, etwa nicht gefundene Ergebnisse für gelöschte Datensätze, prüfen Sie gezielt auf diese Fehlercodes und lassen Sie den Rest scheitern.

Weiterlesen

HTTP-Benchmark-Tools: wrk, hey, oha, ab und weitere

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Die HTTP-Benchmark-Tools für die Kommandozeile, zu denen die meisten Teams greifen, sind wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon und h2load. Nehmen Sie wrk2, wenn Sie eine konstante Anfragerate und ehrliche Tail-Latenzen brauchen, hey oder oha für einen schnellen Check, der auch HTTP/2 spricht, h2load, wenn HTTP/2 oder HTTP/3 selbst auf dem Prüfstand steht, und autocannon, wenn Ihr Team mit Node.js arbeitet.

Wir haben die Tools nicht gegeneinander antreten lassen, deshalb finden Sie hier weder Geschwindigkeitswerte noch ein Urteil über das „schnellste“ Tool. Die Fakten stammen aus dem Repository, dem Handbuch oder der Release-Seite des jeweiligen Projekts (geprüft am 9. Oktober 2026); die Empfehlungen, wann welches Tool passt, sind unsere Einschätzung.

Tool	Geschrieben in	Lizenz	Ratensteuerung	HTTP/2	Letztes Release
wrk	C, LuaJIT-Skripte	Modified Apache 2.0	Keine	Nicht dokumentiert	Tag 4.2.0, Feb. 2021
wrk2	C	Apache 2.0	Konstant (`-R`)	Nicht dokumentiert	Keines, letzter Commit Sep. 2019
hey	Go	Apache 2.0	Limit pro Worker (`-q`)	Ja	v0.1.5, Jan. 2026
oha	Rust	MIT	Gesamtlimit (`-q`)	Ja, dazu HTTP/3	v1.16.0, Aug. 2026
ab	C (Apache httpd)	Apache 2.0	Keine	Nein	httpd 2.4.69, Okt. 2026
bombardier	Go	MIT	Limit (`-r`)	Ja	v2.0.2, März 2025
autocannon	Node.js	MIT	Limit (`-R`)	Nein	v8.0.0, Okt. 2024
h2load	C++ (nghttp2)	MIT	Pro Client (`--rps`)	Ja, dazu HTTP/3	nghttp2 v1.70.0, Juli 2026
Vegeta	Go	MIT	Konstant (`-rate`)	Ja	v12.13.0, Okt. 2025

Warum ist es wichtig, ob ein Tool die Rate festhält?

Ein Tool mit einer festen Zahl von Verbindungen sendet weniger, sobald der Server langsamer wird, und seine Latenzwerte lassen dann die Zeit weg, die Anfragen mit Warten verbracht haben. Ein Tool mit fester Rate sendet nach Plan weiter, und die Verlangsamung zeigt sich in den Perzentilen.

Die meisten Tools hier arbeiten mit einer festen Zahl von Verbindungen oder Workern (-c), die jeweils auf eine Antwort warten, bevor sie weitersenden. Die README von wrk2 nennt diesen blinden Fleck Coordinated Omission und misst jede Anfrage ab dem Zeitpunkt, zu dem sie hätte gesendet werden sollen. Auch Vegeta hält eine konstante Rate; mehr dazu in unserem Überblick über Open-Source-Lasttest-Tools. oha und autocannon können ihre Latenzwerte um denselben Effekt korrigieren, wenn eine Rate gesetzt ist, während hey und bombardier ihre Ratenoptionen nur als Obergrenzen dokumentieren.

Lohnt sich wrk noch?

Ja, für einen schnellen Blick darauf, wie viel Last ein einzelner Rechner auf einen Endpunkt bringen kann, gelesen mit dem Vorbehalt von oben. Der neueste Tag stammt vom Februar 2021.

wrk ist in C geschrieben und hält über mehrere Threads eine feste Zahl von Verbindungen offen. Optionale LuaJIT-Skripte können Anfragen bauen, Antworten verarbeiten und eigene Berichte schreiben, und make baut das Tool zusammen mit dem mitgelieferten LuaJIT und OpenSSL. Ausgegeben werden Mittelwert, Standardabweichung und Maximum der Latenz; --latency ergänzt das 50., 75., 90. und 99. Perzentil.

Wählen Sie stattdessen wrk2, wenn Sie eine feste Anfragerate brauchen oder Tail-Latenzen, denen Sie auch bei einer Verlangsamung trauen können.

Wann brauchen Sie wrk2 statt wrk?

Wenn die Frage lautet, wie sich die Latenz bei einer bestimmten Anfragerate verhält. wrk2 hält diese Rate konstant und erfasst jede Latenz in einem HdrHistogram.

wrk2 ergänzt wrk um ein Durchsatz-Argument (-R, Anfragen pro Sekunde). --latency gibt das vollständige Perzentilspektrum aus, --u_latency ergänzt zum Vergleich die unkorrigierten Werte. Die README warnt, dass Läufe unter 10 bis 20 Sekunden wegen einer 10-sekündigen Kalibrierungsphase wenig aussagen können, und bezeichnet das Projekt als experimentell. Releases gibt es keine, und das Makefile baut ein Binary, das ebenfalls wrk heißt; halten Sie die beiden also auseinander.

Wählen Sie stattdessen oha oder autocannon, wenn Sie eine Ratenoption mit Latenzkorrektur aus einem Projekt wollen, das noch gepflegt wird.

Sind hey und oha austauschbar?

Für schnelle Checks weitgehend: Beide lassen einen Pool von Workern für eine Anzahl Anfragen oder eine feste Dauer laufen, und beide sprechen HTTP/2. Sie unterscheiden sich bei der Ratenbegrenzung und darin, was Sie während eines Laufs sehen.

hey ist ein kleines Go-Programm mit fertigen Binaries für Linux, macOS und Windows und einer Homebrew-Formel. -q begrenzt die Anfragen pro Sekunde für jeden Worker, -h2 schaltet HTTP/2 ein, und die Zusammenfassung enthält ein Antwortzeit-Histogramm und eine Latenzverteilung, mit -o csv auch als CSV.

oha ist in Rust geschrieben, von hey inspiriert und zeigt eine Live-Oberfläche im Terminal. Sein -q setzt eine Gesamtrate, --latency-correction korrigiert um Coordinated Omission, und --http-version akzeptiert 1.1, 2 und in einem experimentellen Build auch 3. Installiert wird es über cargo, Homebrew, winget oder pacman, und es kann JSON oder CSV schreiben.

Wählen Sie stattdessen hey, wenn ein Limit pro Worker zu Ihrer Vorstellung von Last passt; wählen Sie oha für HTTP/3, JSON oder Latenzkorrektur.

Sollten Sie ab noch verwenden?

Für einen schnellen Check auf einem Rechner, auf dem es schon installiert ist, ja. ab wird mit dem Apache HTTP Server ausgeliefert, und sein eigenes Handbuch nennt bekannte Grenzen.

ab nimmt eine Anzahl Anfragen (-n) und eine Nebenläufigkeit (-c) entgegen, hat keine Option für eine Rate oder für HTTP/2 und nutzt KeepAlive nur mit -k. Die Ausgabe endet mit dem Anteil der Anfragen, die innerhalb einer bestimmten Zeit beantwortet wurden; diese Anteile schreibt ab auf Wunsch als CSV (-e), jede einzelne Messung als gnuplot-Datei (-g). Der Abschnitt „Bugs“ im Handbuch sagt, dass ab HTTP/1.x nicht vollständig implementiert, und warnt, dass Sie wegen des aufwendigen String-Parsings womöglich die Leistung von ab selbst messen.

Wählen Sie stattdessen hey oder oha, wenn Sie HTTP/2, ein Ratenlimit oder standardmäßig Keep-Alive brauchen.

Wofür eignen sich bombardier und autocannon?

bombardier ist ein Go-Tool mit optionalem HTTP/2 und Ratenlimit. autocannon passt zu Node.js-Teams, weil es auch als Bibliothek in einem Node-Skript läuft.

bombardier nutzt standardmäßig den fasthttp-Client und wechselt mit --http1 oder --http2 zum net/http-Client von Go. -r setzt ein Ratenlimit, -l gibt das 50., 75., 90. und 99. Perzentil aus, und -o json macht das Ergebnis maschinenlesbar.

autocannon beschreibt sich als HTTP/1.1-Tool mit Pipelining und HTTPS und wird mit npm i autocannon -g installiert. -R begrenzt die Gesamtrate, -r die Rate pro Verbindung, und sobald eine davon gesetzt ist, wird die Latenz um Coordinated Omission korrigiert. Die Tabelle zeigt das 2,5., 50., 97,5. und 99. Perzentil, -l gibt alle aus und -j schreibt JSON.

Wählen Sie autocannon statt bombardier, wenn Ihre Benchmarks in einer Node.js-Testsuite leben, und bombardier, wenn Sie HTTP/2 brauchen.

Welches Tool ist für HTTP/2 und HTTP/3 gebaut?

h2load. Es stammt aus dem nghttp2-Projekt, bevorzugt HTTP/2 und kann HTTP/1.1 erzwingen oder, wenn mit Unterstützung gebaut, HTTP/3.

h2load wird zusammen mit nghttp2 kompiliert, wenn Sie ./configure die Option --enable-app mitgeben. Neben der Zahl der Clients (-c) legt es die gleichzeitigen Streams pro Client fest (-m), um Multiplexing unter Last zu prüfen, und --rps setzt die Anfragen pro Sekunde für jeden Client. Das Handbuch nennt Minimum, Maximum, Mittelwert, Median, p95 und p99 für Anfragezeit, Verbindungsaufbau und Zeit bis zum ersten Byte. Die HTTP/3-Unterstützung ist als experimentell gekennzeichnet.

Wählen Sie stattdessen oha, wenn Sie HTTP/2 mit weniger Optionen und einer Live-Ansicht wollen.

Wann sollten Sie vom Benchmark zu einem echten Lasttest wechseln?

Wenn es um Nutzerabläufe geht, um mehr Last, als ein Rechner erzeugen kann, oder um Traffic von dort, wo Ihre Nutzer sind.

Jedes Tool hier schickt einfache Anfragen von einem einzigen Rechner, und die h2load-Anleitung weist darauf hin, dass der Client selbst zum Engpass werden kann. Wechseln Sie zu einem Lasttest-Tool, wenn Sie Logins, mehrstufige Abläufe oder Think Time brauchen, wenn der Traffic aus mehreren Regionen kommen muss oder wenn ein Test in der CI bestehen oder scheitern soll. Unsere Anleitung Lasttest durchführen geht das Schritt für Schritt durch, und k6 vs Artillery vergleicht zwei skriptbare Tools.

LoadFocus, der Herausgeber dieser Website, führt Lasttests für Websites und APIs aus 25 Cloud-Regionen aus, mit JMeter, k6 oder No-Code-Tests. Wenn Ihr Benchmark eine Anfrage ist, die Sie ohnehin mit curl senden, macht der kostenlose cURL-zu-k6-Konverter daraus direkt im Browser ein k6-Skript.

FAQ

Was ist der Unterschied zwischen wrk und wrk2? wrk2 ist ein Fork von wrk, der Anfragen mit einer konstanten, per -R gesetzten Rate sendet und jede Anfrage ab dem Zeitpunkt misst, zu dem sie hätte gesendet werden sollen. wrk hält eine feste Zahl von Verbindungen beschäftigt und hat keine Ratenoption.

Welche HTTP-Benchmark-Tools unterstützen HTTP/2? Laut ihrer Dokumentation hey, oha, bombardier, h2load und Vegeta. wrk und wrk2 dokumentieren es nicht, autocannon beschreibt sich als HTTP/1.1-Tool, und ab hat keine HTTP/2-Option.

Weiterlesen

Little's Law im Lasttest: Tests dimensionieren und prüfen

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Little's Law im Lasttest besagt, dass die durchschnittliche Zahl der Benutzer oder Anfragen in einem System gleich der Rate ist, mit der sie es durchlaufen, mal der durchschnittlichen Zeit, die jede dort verbringt: L = λW. Bei einer festen Zahl virtueller Benutzer heißt das Benutzer = Durchläufe pro Sekunde × (Antwortzeit + Think Time), und damit sehen Sie vor einem Lauf, ob ein Plan seine Zielrate erreichen kann, und danach, ob die Ergebnisse zusammenpassen. Die Formel arbeitet mit Durchschnitten über eine stabile Phase des Tests und sagt deshalb nichts über Perzentile.

Die Rechenbeispiele unten sind reine Arithmetik ohne Testlauf dahinter. Die Fakten zu Tools stammen aus der Dokumentation der jeweiligen Projekte, geprüft am 9. Oktober 2026.

Größe	Littles Definition	Feste virtuelle Benutzer (geschlossenes Modell)	Ankunftsrate (offenes Modell)
L	Durchschnittliche Zahl der Einheiten im System	Virtuelle Benutzer, wartend oder pausierend	Laufende Iterationen
λ	Durchschnittliche Ankunftsrate	Abgeschlossene Durchläufe pro Sekunde	Die eingestellte Rate
W	Durchschnittliche Verweilzeit	Antwortzeit + Think Time pro Durchlauf	Dauer einer Iteration

Was besagt Little's Law?

Die langfristige durchschnittliche Zahl der Einheiten in einem Warteschlangensystem ist gleich ihrer durchschnittlichen Ankunftsrate mal der durchschnittlichen Zeit, die jede darin verbringt. Kennen Sie zwei der drei Größen, können Sie die dritte ausrechnen.

John D. C. Little veröffentlichte den Beweis 1961 in Operations Research unter dem Titel A Proof for the Queuing Formula: L = λW. In seinem Rückblick zum 50. Jubiläum von 2011 schreibt er, dass das Gesetz unter bemerkenswert allgemeinen Bedingungen gilt: für eine einzelne Warteschlange wie für ein ganzes Netz, für eine Teilklasse der Einheiten wie für alle, und unabhängig von der Bedienreihenfolge. Derselbe Text überträgt die Größen auf einen Server: Anfragen in Bearbeitung, Anfragen pro Sekunde und durchschnittliche Antwortzeit.

Was bedeuten L, λ und W in einem Lasttest?

Das hängt davon ab, wo Sie die Systemgrenze ziehen. Um den Server herum ist L die Zahl der laufenden Anfragen und W die Antwortzeit; um den ganzen Durchlauf eines virtuellen Benutzers herum ist L die Zahl aller virtuellen Benutzer und W die Antwortzeit plus Think Time.

In einem geschlossenen Test ist jeder Benutzer immer irgendwo in seinem Durchlauf: Er wartet auf eine Antwort oder pausiert zwischen zwei Schritten. Mit der Grenze um den Durchlauf zählen alle als „im System“, λ ist die Rate, mit der Durchläufe enden, und W die durchschnittliche Dauer eines Durchlaufs, einschließlich der Think Time, die das Skript einfügt:

Benutzer = Durchläufe pro Sekunde × (Antwortzeit + Think Time)

Um den Server herum liefert dasselbe Gesetz die gleichzeitig laufenden Anfragen: Anfragen pro Sekunde × durchschnittliche Antwortzeit, also die Zahl, die Ihre Connection-Pools und Worker-Threads aufnehmen müssen. Halten Sie alle drei Werte auf derselben Grenze und im selben Zeitabschnitt; gemischte Werte ergeben plausible, aber falsche Ergebnisse.

Wie dimensionieren Sie einen geschlossenen Test mit Little's Law?

Rechnen Sie die Zielrate der Anfragen in Durchläufe pro Sekunde um und multiplizieren Sie mit der erwarteten Dauer eines Durchlaufs: Das Ergebnis ist die Zahl der virtuellen Benutzer, die der Plan braucht. Nehmen Sie die Antwortzeit, die Sie unter der Ziellast erwarten; sie liegt meist höher als bei wenigen Benutzern.

Ein Rechenbeispiel, nur Arithmetik. Ziel sind 100 Anfragen pro Sekunde, jeder Durchlauf schickt 4 Anfragen mit erwarteten 0,5 Sekunden pro Anfrage, und das Skript pausiert 3-mal im Schnitt 2 Sekunden:

Durchläufe pro Sekunde = 100 Anfragen/s ÷ 4 Anfragen = 25
Dauer pro Durchlauf    = 4 × 0,5 s + 3 × 2 s         = 8 s
virtuelle Benutzer     = 25 Durchläufe/s × 8 s       = 200

Betrachten Sie 200 als Untergrenze. Dauern die Antworten unter dieser Last 1 Sekunde, wird ein Durchlauf 10 Sekunden lang, und dasselbe Ziel braucht 250 Benutzer.

Warum schicken dieselben Benutzer weniger Anfragen, wenn das System langsamer wird?

Die Zahl der Benutzer ist fest, also müssen die Durchläufe pro Sekunde sinken, wenn ein Durchlauf länger dauert. Die Last fällt genau dann, wenn das System zu kämpfen beginnt.

Bleiben Sie bei den 200 Benutzern und lassen Sie jede Anfrage 2 Sekunden dauern. Ein Durchlauf dauert dann 4 × 2 + 6 = 14 Sekunden, und 200 ÷ 14 ergibt etwa 14,3 Durchläufe oder etwa 57 Anfragen pro Sekunde. Der Test zeigt weiter 200 Benutzer an, läuft aber nur mit gut der Hälfte der geplanten Rate. Der Artikel zum offenen vs geschlossenen Lastmodell erklärt, warum das eine Sättigung verbirgt; Little's Law sagt die Größe des Einbruchs voraus.

Es zeigt auch, wie eine Kapazitätsgrenze aussieht. Kann die Anfragerate nicht weiter steigen, bringt jeder zusätzliche Benutzer nur Wartezeit: Bei einer Obergrenze von 25 Durchläufen pro Sekunde bedeuten 300 Benutzer 12 Sekunden pro Durchlauf und 400 Benutzer 16. Das LoadFocus-Diagramm Antwortzeit vs. virtuelle Benutzer trägt die durchschnittliche und maximale Antwortzeit gegen die Zahl aktiver virtueller Benutzer auf, ein Punkt pro erreichter Benutzerstufe; dort zeigt sich dieser gleichmäßige Anstieg.

Wie prüfen Sie einen abgeschlossenen Test mit Little's Law?

Nehmen Sie die durchschnittliche Anfragerate und Antwortzeit aus einem Abschnitt mit konstanter Benutzerzahl, rechnen Sie daraus die Zahl der Benutzer zurück und vergleichen Sie sie mit Ihrer Konfiguration. Eine große Lücke heißt, dass Zeit an einer Stelle verloren geht, die Ihre Zahlen nicht zeigen.

Noch ein Rechenbeispiel. Ein Lauf hält 200 Benutzer und meldet 80 Anfragen pro Sekunde bei durchschnittlich 0,6 Sekunden, mit denselben 4 Anfragen und 6 Sekunden Pausen pro Durchlauf. Das sind 20 Durchläufe pro Sekunde zu je 4 × 0,6 + 6 = 8,4 Sekunden, genug für 168 Benutzer. Die übrigen 32 bedeuten, dass jeder Durchlauf in Wahrheit 10 Sekunden dauerte, also bleiben etwa 1,6 Sekunden pro Durchlauf unerklärt. Wo Sie suchen sollten:

Verbindungsaufbau. In k6 enthält http_req_duration weder DNS-Auflösung noch Verbindungsaufbau (Metrik-Referenz, geprüft am 9. Oktober 2026).
Der Lastgenerator. Ein ausgelasteter Generator verzögert das Skript zwischen den Anfragen.
Think Time. Zufällige Pausen können im Schnitt länger ausfallen als im Plan.
Das Zeitfenster. Überschneidet es sich mit einer Rampe, waren im Schnitt weniger Benutzer aktiv.

k6 misst den Durchlauf auch direkt: vus zählt die aktiven virtuellen Benutzer und iteration_duration die Dauer einer vollständigen Iteration, also sollten die aktiven Benutzer nahe bei Iterationen pro Sekunde × durchschnittlicher Iterationsdauer liegen.

Was gilt für Tests mit Ankunftsrate?

Das Gesetz gilt mit der Grenze um jede Iteration: Die laufenden Iterationen sind gleich der Ankunftsrate mal der Iterationsdauer. So viele virtuelle Benutzer muss das Tool bereithalten.

Die k6-Anleitung zur VU-Zuteilung für Arrival-Rate-Executors schätzt sie als mediane Iterationsdauer × Rate plus eine Konstante für die Streuung (geprüft am 9. Oktober 2026). Das ist Little's Law mit dem Median an Stelle des Mittelwerts; einige langsame Iterationen ziehen den Mittelwert über den Median, deshalb zählt der Puffer.

LoadFocus führt k6-Skripte in seiner Cloud aus, und dort laufen Arrival-Rate-Szenarien mit einer festen Zahl von Benutzern; der Skript-Validator weist beim Hinzufügen eines solchen Skripts darauf hin. Dimensionieren Sie diese Tests mit der Rechnung für das geschlossene Modell und rechnen Sie damit, dass die Rate fällt, wenn die Antworten langsamer werden.

Wo hört Little's Law auf zu funktionieren?

Das Gesetz verknüpft Durchschnitte über einen Abschnitt, in dem das System im Gleichgewicht ist. Perzentile, kurze Zeitfenster und Rampen liegen außerhalb davon.

Nur Durchschnitte. Ein Lauf kann das Gesetz erfüllen, während jede zwanzigste Anfrage zehnmal so lange wartet wie der Mittelwert; bewerten Sie Ergebnisse also auch nach Perzentilen.
Eine stabile Phase. Der Beweis von 1961 setzt einen stationären Prozess voraus, und der Rückblick von 2011 zeigt, dass die Formel auch über ein endliches Zeitfenster exakt gilt, das leer beginnt und leer endet. Ein Testplateau ist beides nicht, also wählen Sie ein langes, in dem so viele Benutzer Durchläufe beenden, wie neue beginnen.
Rampen. Während Benutzer hinzukommen, ist die konfigurierte Spitze nicht L: Nehmen Sie die zeitlich gemittelte Benutzerzahl des Fensters oder lassen Sie die Rampe weg.
Fehler. Schnelle Fehlschläge zählen als abgeschlossene Anfragen mit kurzer Dauer, sodass auch ein versagendes System die Gleichung erfüllt. Prüfen Sie zuerst die Fehlerrate.

FAQ

Braucht Little's Law Poisson-Ankünfte oder eine bestimmte Warteschlange? Nein. Die Beweise in Littles Rückblick setzen nichts über das Ankunftsmuster oder die Bedienzeiten voraus, und das Ergebnis gilt unabhängig von der Bedienreihenfolge. Nötig sind nur Durchschnitte, die über den gemessenen Zeitraum existieren.

Kann Little's Law p95-Antwortzeiten vorhersagen? Nein. Es verknüpft drei Durchschnitte und kann daher eine mittlere Antwortzeit prüfen, sagt aber nichts über die Form der Verteilung oder die langsamsten paar Prozent.

Weiterlesen

Pass/Fail-Kriterien für Lasttests: so legen Sie sie fest

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Pass/Fail-Kriterien für Lasttests sind die wenigen Grenzwerte, die ein Lauf einhalten muss, um als bestanden zu gelten: ein Latenz-Perzentil für die Anfragen, auf die Nutzer warten, eine Fehlerrate und eine Mindestrate an Anfragen, jeweils bei einer festgelegten Last. Leiten Sie die Grenzwerte aus einem Service Level Objective (SLO) ab, legen Sie Regressionsgrenzen aus früheren Läufen innerhalb davon fest und lassen Sie den Exit-Code des Tools den Lauf nur an diesen harten Grenzwerten scheitern. Alles andere ist eine Warnung, die ein Mensch liest.

Die Angaben zu den Tools wurden am 9. Oktober 2026 in der Dokumentation des jeweiligen Projekts geprüft, und jeder gezeigte Grenzwert ist ein Beispiel.

Kriterium	Beispielgrenze	Woher die Zahl kommt	Bei Verfehlen
p95-Latenz, Checkout	Unter 400 ms	Latenz-SLO minus Reserve	Fehlschlag
p99-Latenz, Checkout	Unter 1.200 ms	Frühere Läufe dieses Tests	Warnung
Fehlerrate	Unter 0,5 %	Verfügbarkeits-SLO	Fehlschlag
Anfragen pro Sekunde	Mindestens 95 % des Plans	Die geplante Last	Fehlschlag
CPU des Lastgenerators	Unter 80 %	Tool oder Plattform	Lauf ungültig

Wann besteht ein Lasttest, und wann scheitert er?

Ein Lauf besteht, wenn jeder harte Grenzwert bei der geplanten Last hält, und scheitert, sobald einer verfehlt wird. Ungültig ist er, wenn der Test selbst seine Aufgabe nicht erfüllt hat, ganz gleich, was die Zahlen sagen.

Ein ausgelasteter Lastgenerator, eine Last, die ihr Ziel nie erreicht hat, oder ein fehlerhaftes Skript liefern Zahlen über den Testaufbau. LoadFocus zeigt zum Beispiel eine Warnung zur Sättigung des Lastgenerators, wenn eine Engine in der Spitze 80 % CPU oder mehr erreicht hat. Die Exit-Codes von k6 trennen die Fälle für die CI: 99 steht für verfehlte Schwellenwerte, 107 für eine Exception im Skript (geprüft am 9. Oktober 2026).

Wie wird aus einem SLO ein Kriterium für den Lasttest?

Formulieren Sie jedes SLO, das unter Last brechen kann, meist Latenz und Verfügbarkeit, als Grenzwert für das, was der Test misst, und machen Sie ihn strenger als das SLO, damit ein Bestehen Luft lässt.

Googles SRE-Buch definiert ein SLO als Zielwert oder Wertebereich für ein Service-Level, gemessen durch einen Indikator (SLI), mit Beispielen wie: 99 % der Get-Aufrufe sind in unter 100 ms fertig. Es verlangt, dass ein SLO angibt, wie es gemessen wird und wann es gilt, und empfiehlt eine Sicherheitsreserve: ein internes Ziel, das strenger ist als das, was Nutzer zugesagt bekommen.

Bei einem Lasttest bedeutet „wann es gilt“ die Last und den Anfragemix. Aus „95 % der Checkout-Aufrufe unter 500 ms“ könnte zum Beispiel „p95 des Checkouts unter 400 ms bei 300 Anfragen pro Sekunde über 15 Minuten“ werden. Gibt es noch kein SLO, vereinbaren Sie ein vorläufiges mit dem Product Owner.

Welche Metriken sollten die Kriterien abdecken?

Latenz für die Anfragen, auf die Nutzer warten, eine Fehlerrate, die erreichte Anfragerate und, meist als Warnung, die Ressourcen der Server.

Latenz pro Anfragetyp. Ein globales Perzentil mischt einen schnellen Health Check mit einer langsamen Suche. In k6 erzeugen getaggte Anfragen Sub-Metriken mit eigenen Grenzwerten; in Gatling zielt details() auf eine einzelne Anfrage oder Gruppe. Ein Test, der seine eigene Last gebremst hat, meldet geschönte Perzentile (Coordinated Omission).
Fehler, weit gefasst. Eine schnelle 200 mit Fehlerseite bleibt ein Fehler, prüfen Sie also den Inhalt. Eine fehlgeschlagene JMeter-Response Assertion markiert ihr Sample als nicht erfolgreich; k6-Checks wirken nur über einen Schwellenwert auf den Exit-Code.
Eine Untergrenze für die Anfragerate. Im geschlossenen Lastmodell erhält ein langsames System weniger Anfragen, sodass ein Lauf seine Latenzgrenzen bei einem Bruchteil der geplanten Last einhalten kann (offenes vs geschlossenes Lastmodell).
Ressourcen der Server. CPU, Speicher und Pool-Auslastung kommen aus Ihrem Monitoring. Behandeln Sie sie als Warnungen, solange kein Kapazitätsplan eine harte Obergrenze setzt.

Wie wählt man die Zahlen?

Die Obergrenze kommt aus dem SLO, die Regressionsgrenze aus früheren Läufen desselben Tests. Das SLO sagt, was Nutzer hinnehmen; frühere Läufe zeigen, was dieser Build normalerweise leistet.

Das SRE-Buch warnt davor, ein SLO aus der aktuellen Performance abzuleiten. Eine Regressionsgrenze soll Veränderungen bemerken, also ist die aktuelle Performance genau ihr Ausgangspunkt. Lassen Sie den unveränderten Build mehrmals mit derselben Umgebung und Last laufen, notieren Sie, wie weit jede Metrik schwankt, und setzen Sie die Grenze mit etwas Reserve über den schlechtesten Lauf, aber unter die aus dem SLO abgeleitete Obergrenze, wo es eine gibt.

Schwanken Läufe desselben Builds stärker als die Regression, die Sie erkennen wollen, ist der Test zu verrauscht, um Builds zu blockieren: Verlängern Sie zuerst die stabile Phase oder isolieren Sie die Umgebung. Erfassen Sie nach jeder bewussten Änderung neue Referenzläufe.

Welche Kriterien sollten den Build scheitern lassen, und welche nur warnen?

Lassen Sie den Build an Grenzwerten scheitern, die aus einem SLO stammen oder Korrektheit prüfen. Warnen Sie bei Tail-Perzentilen, Ressourcenverbrauch und langsamen Drifts, die eine Einschätzung brauchen; ein Gate, das an Rauschen scheitert, wird bald abgeschaltet.

Das ensure-Plugin von Artillery hat eine Warnstufe: Eine Bedingung mit strict: false ist optional, ein Verfehlen lässt den Exit-Code also unberührt (geprüft am 9. Oktober 2026). In k6 lässt ein Check ohne Schwellenwert den Lauf nie scheitern. In anderen Tools gehören Warnungen nicht in die Assertions.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

Wann sollte ein Lasttest vorzeitig abbrechen?

Wenn Weitermachen nur schaden oder nichts mehr beweisen kann: Fehler weit über der Grenze, ein System, das schon ausgefallen ist, oder ein Generator, der nicht mehr mithält. Geben Sie der Regel eine Schonfrist, damit Rauschen beim Start sie nicht auslöst.

Setzen Sie Abbruchregeln lockerer an als die Grenzen fürs Bestehen: Sie schützen eine gemeinsam genutzte Umgebung. abortOnFail stoppt einen k6-Test, sobald ein Schwellenwert verfehlt ist, nach einem optionalen delayAbortEval. Die Doku von Locust zu Erweiterungen zeigt ein Greenlet im Hintergrund, das den Lauf beendet, sobald die Fehlerquote eine Schwelle überschreitet. crashLoadGeneratorIf stoppt in Gatling den Generator mit einem Fehlercode, wenn eine Bedingung in der Session eines virtuellen Benutzers zutrifft. Eine JMeter-Thread Group kann den Test bei einem Sampler-Fehler stoppen, was zu einer Korrektheitsprüfung passt (alles geprüft am 9. Oktober 2026).

Wie setzt jedes Tool die Kriterien um?

k6 und Artillery machen aus einem verfehlten harten Grenzwert einen Exit-Code ungleich null, Locust tut das bei jeder fehlgeschlagenen Anfrage oder bei selbst programmierten Grenzwerten, und die Assertions von Gatling lassen den Build scheitern. JMeter überlässt das Urteil einem Schritt nach dem Lauf.

k6: Die Schwellenwerte stehen in den Optionen des Skripts. Dieses Beispiel scheitert am p95 der mit name: checkout getaggten Anfragen oder an 0,5 % Fehlern und bricht nach einer Minute ab, wenn die Fehler 5 % übersteigen:

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling: Die Assertions verbinden einen Geltungsbereich (global, forAll, details), eine Statistik wie ein Perzentil oder requestsPerSec und eine Bedingung. Sie werden nach dem Lauf ausgewertet, und eine fehlgeschlagene Assertion lässt die Simulation scheitern.

Locust beendet sich mit Exit-Code 1, wenn mindestens eine Anfrage fehlgeschlagen ist, und --exit-code-on-error ändert diesen Code. Für eine Quote oder ein Perzentil setzen Sie environment.process_exit_code in einem quitting-Listener; laut Quellcode von Locust hat dieser Wert Vorrang.

JMeter bewertet mit Assertions einzelne Samples, und seine Kommandozeilenoptionen kennen keinen Grenzwert für den ganzen Lauf. Die CI entscheidet: mit einem kurzen Skript über die Ergebnisdatei, wie in unserem Leitfaden zu GitHub Actions, oder mit dem jmeter-maven-plugin eines Drittanbieters, dessen results-Goal den Build bei jedem fehlgeschlagenen Sample scheitern lässt, sofern errorRateThresholdInPercent keine Rate vorgibt (geprüft am 9. Oktober 2026).

LoadFocus bewertet Läufe anhand von Pass/Fail-Schwellenwerten, die am Test gespeichert sind: maximale p95- und p99-Antwortzeit, maximale Fehlerrate und minimale Anfragerate, jeweils optional. Jeder Lauf erhält ein PASS- oder FAIL-Badge mit Ist- und Zielwerten, und eine API gibt das Urteil an eine Pipeline weiter. LoadFocus führt k6-Szenarien mit Ankunftsrate mit einer festen Zahl von Benutzern aus; dort prüft eine Untergrenze für die Rate also, was diese Benutzer erreicht haben.

FAQ

Sollte die durchschnittliche Antwortzeit ein Pass/Fail-Kriterium sein? Selten. Das SRE-Buch bevorzugt Perzentile: Ein Durchschnitt verdeckt die langsamen Ausreißer am Ende der Verteilung und kann flach bleiben, während die langsamsten Anfragen deutlich langsamer werden.

Wie viele Pass/Fail-Kriterien sollte ein Lasttest haben? Eine Handvoll harter Grenzwerte, dazu Warnungen. Das SRE-Buch rät zu so wenigen SLOs wie möglich und sagt: Wenn man mit einem SLO nie eine Diskussion über Prioritäten gewinnen kann, lohnt es sich wahrscheinlich nicht. Legen Sie an jeden Grenzwert eines Lasttests denselben Maßstab an.

Kann ein Lasttest mit einigen fehlgeschlagenen Anfragen bestehen? Ja, wenn die Fehlerrate unter ihrer Grenze bleibt. Prüfen Sie die Voreinstellung Ihres Tools: Locust lässt den Lauf bei jeder fehlgeschlagenen Anfrage scheitern.

Weiterlesen

Lasttests in GitHub Actions: ein praktischer Leitfaden

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Für Lasttests in GitHub Actions genügt eine Workflow-Datei: Tool installieren, einen kurzen Test gegen eine Staging-URL starten und den Job über den Exit-Code des Tools scheitern lassen, wenn ein Schwellenwert verfehlt wird. Laden Sie die Ergebnisse als Artefakt hoch, damit jeder Lauf eine Spur hinterlässt. Halten Sie den Test klein, denn ein Standard-Runner von GitHub ist eine einzelne virtuelle Maschine mit wenigen CPU-Kernen.

Die Angaben zu den Tools und zu GitHub stammen aus der Dokumentation der jeweiligen Anbieter, geprüft am 9. Oktober 2026, und die Workflows folgen dieser dokumentierten Verwendung.

Tool	Installiert über	Was den Job scheitern lässt	Ergebnisse zum Aufbewahren
k6	Grafanas `setup-k6-action`	Ein verfehlter Schwellenwert	JSON-Ausgabe
Artillery	`artilleryio/action-cli`	Eine fehlgeschlagene `ensure`-Prüfung	`report.json`
Locust	`pip install locust`	Jede fehlgeschlagene Anfrage oder eine eigene Regel	CSV- und HTML-Dateien
JMeter	Das Release-Archiv	Nichts eingebaut: einen Prüfschritt ergänzen	`.jtl`-Datei und HTML-Bericht

Was braucht ein Lasttest-Workflow?

Einen Trigger, einen Runner, einen Schritt, der das Tool installiert, einen Schritt, der den Test mit Schwellenwerten ausführt, und einen Schritt, der die Ergebnisse hochlädt. Alles andere ist optional.

Legen Sie das Testskript ins Repository, etwa unter tests/load/. Lesen Sie die Staging-URL aus einer Repository-Variablen über den vars-Kontext und setzen Sie timeout-minutes für den Job: Der Standardwert liegt bei 360 Minuten (geprüft am 9. Oktober 2026).

Welche Ereignisse sollten einen Lasttest starten?

Lassen Sie bei Pull Requests einen kurzen Test laufen und einen längeren nach Zeitplan oder von Hand.

Nutzen Sie pull_request, um eine Regression vor dem Merge zu erkennen, workflow_dispatch für manuelle Läufe und schedule für Cron-Läufe (in UTC, sofern Sie keine Zeitzone angeben). GitHubs Referenz der Ereignisse nennt einige Grenzen (geprüft am 9. Oktober 2026): Zeitpläne laufen nur auf dem Standard-Branch, höchstens alle fünf Minuten, und können sich zur vollen Stunde verzögern. Pull Requests aus Forks erhalten außer GITHUB_TOKEN keine Secrets.

Wie führt man k6 in GitHub Actions aus?

Nutzen Sie die zwei offiziellen Actions von Grafana, eine zum Installieren von k6 und eine zum Ausführen des Skripts. Der Schritt schlägt fehl, sobald k6 mit einem Exit-Code ungleich null endet, und genau das löst ein verfehlter Schwellenwert aus.

Sowohl setup-k6-action als auch run-k6-action stehen auf v1 (geprüft am 9. Oktober 2026):

name: load-test
on:
  pull_request:
  workflow_dispatch:

jobs:
  k6:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      BASE_URL: ${{ vars.STAGING_URL }}
    steps:
      - uses: actions/checkout@v7
      - uses: grafana/setup-k6-action@v1
      - uses: grafana/run-k6-action@v1
        with:
          path: tests/load/smoke.js
          flags: --out json=results.json
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: k6-results
          path: results.json
          retention-days: 14

Die Schwellenwerte stehen im Skript, das BASE_URL aus der Umgebung liest:

import http from "k6/http";

export const options = {
  vus: 10,
  duration: "1m",
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"],
  },
};

export default function () {
  http.get(`${__ENV.BASE_URL}/health`);
}

Laut k6-Dokumentation beeinflussen Checks den Exit-Status nicht, daher muss die Entscheidung über Bestehen oder Scheitern von den Schwellenwerten kommen.

Wie führt man stattdessen Artillery, Locust oder JMeter aus?

Tauschen Sie die Installations- und Ausführungsschritte aus, behalten Sie den Rest des Workflows und nutzen Sie den Mechanismus des jeweiligen Tools, um bei einem verfehlten Ziel zu scheitern.

Artillery hat eine offizielle GitHub Action, deren README festhält, dass @v2 dem neuesten 2.x-Release folgt (geprüft am 9. Oktober 2026). Der Schritt lautet uses: artilleryio/action-cli@v2 mit command: run --target ${{ vars.STAGING_URL }} tests/load/api.yml --output report.json, und das ensure-Plugin beendet Artillery mit einem Exit-Code ungleich null, wenn ein Ziel verfehlt wird. Der Abschnitt config des Skripts:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 5
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500

Locust endet mit Exit-Code 1, sobald eine Anfrage fehlgeschlagen ist, und für Latenzregeln setzen Sie environment.process_exit_code in einem Listener für das quitting-Ereignis, wie dieselbe Seite zeigt (geprüft am 9. Oktober 2026). Nach actions/setup-python@v7 mit python-version: "3.13":

      - run: pip install locust
      - run: >
          locust -f tests/load/locustfile.py --headless
          -u 20 -r 5 -t 2m -H "$BASE_URL"
          --csv results --html report.html

JMeter läuft mit -n ohne Oberfläche, und die Kommandozeilenoptionen im Benutzerhandbuch enthalten keinen Pass/Fail-Schwellenwert (geprüft am 9. Oktober 2026). Ein kurzer Schritt kann die Ergebnisdatei lesen, standardmäßig CSV mit einer Spalte success, und den Job selbst scheitern lassen:

      - uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: "21"
      - name: Install JMeter 5.6.3
        env:
          JM_BASE: https://archive.apache.org/dist/jmeter/binaries
        run: curl -sSL "$JM_BASE/apache-jmeter-5.6.3.tgz" | tar -xzf -
      - name: Run the test plan
        run: >
          apache-jmeter-5.6.3/bin/jmeter -n -t tests/load/plan.jmx
          -l results.jtl -e -o report
      - name: Fail above 1% errors
        run: |
          python3 - <<'EOF'
          import csv, sys
          rows = list(csv.DictReader(open("results.jtl")))
          bad = sum(r["success"] != "true" for r in rows)
          print(f"{bad} of {len(rows)} samples failed")
          sys.exit(1 if not rows or bad > 0.01 * len(rows) else 0)
          EOF

Wie lässt man den Job scheitern, wenn der Test ein Ziel verfehlt?

Schreiben Sie die Ziele als Schwellenwerte in den Test und überlassen Sie den Rest dem Exit-Code. GitHub markiert einen Schritt als fehlgeschlagen, wenn sein Befehl mit einem Exit-Code ungleich null endet, und der Job scheitert mit ihm.

Beginnen Sie mit einer strengen Fehlerquote und einem großzügigen Latenz-Perzentil, und verschärfen Sie das Latenzlimit, sobald Sie wissen, wie stark Ihre Zahlen von Lauf zu Lauf schwanken. Wie Sie diese Ziele festlegen, zeigt die Schritt-für-Schritt-Anleitung zum Lasttest.

Wohin gehören die Ergebnisse jedes Laufs?

Laden Sie sie als Workflow-Artefakt hoch, mit if: always(), damit auch ein fehlgeschlagener Test seinen Bericht behält. Artefakte werden standardmäßig 90 Tage aufbewahrt, und retention-days verkürzt das.

Das README von upload-artifact dokumentiert die 90 Tage als Standard (geprüft am 9. Oktober 2026). Setzen Sie if-no-files-found: error, damit der Schritt bei einem fehlenden Bericht sichtbar fehlschlägt.

Wie viel Last kann ein von GitHub gehosteter Runner erzeugen?

Genug für einen Smoke-Test oder eine kleine Regressionsprüfung. Ein Standard-Linux-Runner hat in öffentlichen Repositories 4 CPUs und 16 GB RAM, in privaten 2 CPUs und 8 GB, und ein Job endet nach 6 Stunden.

Diese Zahlen stammen aus GitHubs Runner-Referenz und den Actions-Limits (geprüft am 9. Oktober 2026), die keine Angabe zur Netzwerkbandbreite machen.

Ein Job läuft auf einer Maschine und ist damit ein einziger Lastgenerator: Ist seine CPU ausgelastet, enthalten die Antwortzeiten auch die Wartezeit auf dem Runner. Jede Anfrage verlässt zudem dieselbe Maschine, sodass Rate Limiter, die pro Client-Adresse zählen, einen einzigen sehr aktiven Client sehen. GitHub rät davon ab, die Azure-IP-Bereiche seiner Ubuntu-Runner in Allowlists aufzunehmen; größere Runner in den Plänen Team und Enterprise Cloud bieten mehr CPU, mehr Speicher und statische IP-Adressen.

Wann sollte die Last von woanders kommen?

Wenn Sie mehr Last brauchen, als eine Maschine erzeugt, Traffic aus mehreren Regionen oder Läufe, die länger dauern als das Job-Limit.

Bei k6 führt run-k6-action den Test in Grafana Cloud k6 aus, wenn Sie cloud-run-locally: false setzen und K6_CLOUD_TOKEN, K6_CLOUD_PROJECT_ID sowie mit k6 v2 K6_CLOUD_STACK_ID übergeben. Ein Cloud-Lauf ignoriert standardmäßig die Umgebung des Runners, ergänzen Sie flags also um -e BASE_URL=${{ vars.STAGING_URL }} (geprüft am 10. Oktober 2026). Die Action von Artillery kann run-fargate oder run-lambda aufrufen und die Last aus Ihrem eigenen AWS-Konto erzeugen (beides geprüft am 9. Oktober 2026). Der Vergleich k6 vs Artillery behandelt beide.

Für JMeter dokumentiert LoadFocus eine Integration mit GitHub Actions auf Basis seines npm-Clients. Sie speichern den Test in Ihrem LoadFocus-Konto, hinterlegen API-Schlüssel und Team-ID als Secrets und rufen run-test auf. Die Flags unten folgen dem Hilfetext des Clients:

      - run: npm install -g @loadfocus/loadfocus-api-client
      - env:
          LF_KEY: ${{ secrets.LOADFOCUS_API_KEY }}
          LF_TEAM: ${{ secrets.LOADFOCUS_TEAM_ID }}
        run: |
          test -n "$LF_KEY"
          test -n "$LF_TEAM"
          loadfocus-api config set \
            --apikey "$LF_KEY" --teamid "$LF_TEAM"
          loadfocus-api jmeter run-test --name checkout-api \
            --thresholds "avgresponse<=200,errors==0,p95<=250"

Der Client wartet standardmäßig bis zu 1.800 Sekunden (--wait-timeout ändert das), setzen Sie timeout-minutes für den Job also auf mehr als 30, etwa 40. Er endet mit Exit-Code 1, wenn ein Schwellenwert verfehlt wird, und mit 0, wenn API-Schlüssel oder Team-ID fehlen, deshalb lassen die test -n-Zeilen den Schritt vorher scheitern, sobald ein Secret leer ist. Die Last kommt von LoadFocus, das JMeter-Skripte aus 25 Cloud-Regionen ausführt.

FAQ

Wie lange sollte ein Lasttest in einem Pull Request laufen? Ein paar Minuten: lang genug, um den Ramp-up hinter sich zu lassen und ein stabiles Perzentil zu erhalten, und kurz genug, dass niemand darauf warten muss.

Darf man Lasttests von GitHub-gehosteten Runnern aus fahren? GitHubs Bedingungen für Actions verbieten, damit Dienste zu stören, und beschränken gehostete Runner auf Arbeit am eigenen Projekt des Repositorys (geprüft am 9. Oktober 2026). Ein Lasttest gegen die eigene Staging-Umgebung dieses Projekts, der GitHubs Server nicht übermäßig belastet, ist die Art von Test, die diese Bedingungen beschreiben.

Kann ich stattdessen einen selbst gehosteten Runner nutzen? Ja. Er läuft auf Ihrer eigenen Hardware und in Ihrem Netzwerk, und laut GitHubs Limits-Seite darf ein Job dort bis zu 5 Tage laufen. Er bleibt ein einziger Lastgenerator.

Weiterlesen

Locust-Lasttests: das Python-Tool im Überblick

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Locust ist ein kostenloses Python-Lasttest-Tool unter MIT-Lizenz, in dem jeder Test ein Python-Programm ist, ausgeführt von leichtgewichtigen Benutzern über eine Web-UI oder die Kommandozeile. Ein Locust-Lasttest passt zu Teams, die Python schreiben und vor allem HTTP-Dienste testen. Wer viele Protokolle ab Werk oder einen grafischen Test-Builder braucht, ist mit JMeter besser bedient, und wer JavaScript schreibt, mit k6.

Wir haben Locust für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation, dem Repository und der PyPI-Seite von Locust, geprüft am 9. Oktober 2026; die Einschätzungen sind unsere eigenen.

Thema	Locust
Lizenz	MIT
Laufzeit	Python 3.11 oder neuer
Aktuelle Version	2.46.7 (4. Oktober 2026)
Tests als	Python-Klassen in einem Locustfile
Ausführung	Web-UI auf Port 8089 oder headless
Eingebaute Protokolle	HTTP und HTTPS
Skalierung	Ein Master und beliebig viele Worker
Ergebnisse	Live-Diagramme, CSV, HTML, JSON, OpenTelemetry
CI	Exit-Code 1, wenn mindestens eine Anfrage fehlgeschlagen ist

Wer entwickelt Locust, und wird es noch gepflegt?

Lars Holmberg pflegt Locust, und Microsoft sponsert die Arbeit. Neue Versionen erscheinen häufig: 17 sind es bisher im Jahr 2026.

Das README von Locust nennt beide. PyPI führt 2.46.7 vom 4. Oktober 2026 als neueste Version und setzt Python 3.11 oder neuer voraus (geprüft am 9. Oktober 2026).

Wie funktioniert ein Locustfile?

Ein Locustfile ist ein gewöhnliches Python-Modul mit mindestens einer User-Klasse. Jeder simulierte Benutzer arbeitet seine Tasks nacheinander ab und pausiert dazwischen für seine wait_time.

Laut der Anleitung zum Locustfile gibt HttpUser jedem Benutzer einen client, der python-requests kapselt, Cookies behält und jede Anfrage erfasst. Mit @task markierte Methoden werden zufällig gewählt, gewichtet mit der Zahl im Decorator, und on_start läuft einmal pro Benutzer. Dieser Benutzer meldet sich an, stöbert viermal so oft, wie er bestellt, und startet höchstens alle 10 Sekunden einen Task:

from locust import HttpUser, task, constant_pacing


class Shopper(HttpUser):
    wait_time = constant_pacing(10)

    def on_start(self):
        self.client.post("/login", json={"user": "demo"})

    @task(4)
    def browse(self):
        self.client.get("/products?page=2", name="/products")

    @task
    def checkout(self):
        with self.client.post(
            "/checkout", catch_response=True
        ) as resp:
            if "order_id" not in resp.text:
                resp.failure("no order id")

Mit catch_response lassen Sie eine Anfrage auch an ihrem Inhalt scheitern, und name fasst wechselnde URLs in einer Zeile der Statistik zusammen. Die übrigen Wartefunktionen sind constant, between, constant_throughput und seit Version 2.46.6 poisson; unser Beitrag zur Think Time im Lasttest erklärt, wie Pausen die Last formen. Die Dokumentation ergänzt, dass die Wartezeit den Durchsatz nur begrenzen und keine Benutzer starten kann, um eine Zielrate zu erreichen. Ein Locust-Test ist also ein fester Pool von Benutzern, ein geschlossenes Lastmodell.

Web-UI oder headless: was sollten Sie nutzen?

Die Web-UI, solange Sie erkunden, und den Headless-Modus für wiederholbare Läufe.

Der Befehl locust startet eine Weboberfläche auf Port 8089. Dort legen Sie Host, Benutzerzahl und Ramp-up fest, verfolgen Live-Diagramme und ändern die Last während des Tests. Der Headless-Modus nimmt dieselben Einstellungen als Flags entgegen:

locust -f locustfile.py --headless -u 200 -r 10 -t 10m \
  --host https://staging.example.com \
  --csv results --html report.html

-u setzt die Zahl der Benutzer, -r die Benutzer, die pro Sekunde starten, und -t die Laufzeit einschließlich Ramp-up. Dieselben Einstellungen lassen sich auch in locust.conf oder pyproject.toml festlegen.

Wie funktioniert der verteilte Modus?

Ein Master-Prozess betreibt die Web-UI und koordiniert, Worker-Prozesse führen die Benutzer aus und melden ihre Ergebnisse zurück. Sie brauchen einen Worker pro CPU-Kern, weil ein Python-Prozess nicht mehr als einen Kern voll nutzen kann.

Laut der Dokumentation zur verteilten Last schafft ein Prozess bei einem einfachen Testplan über tausend Anfragen pro Sekunde; größere Tests verteilen Sie deshalb:

# auf dem Master-Rechner
locust -f locustfile.py --master
# auf jedem Worker-Rechner, ein Worker pro Kern
locust -f - --worker --master-host 10.0.0.5 --processes -1

-f - holt das Locustfile vom Master. --processes setzt auf fork() und funktioniert deshalb nicht unter Windows, und nach jeder Änderung am Locustfile müssen alle Prozesse neu starten. Die Dokumentation beschreibt außerdem einen Kubernetes-Operator und Azure Load Testing (geprüft am 9. Oktober 2026).

LoadFocus, der Herausgeber dieser Website, führt keine Locust-Tests aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus, und zwar aus 25 Cloud-Regionen. Für Locust bleiben also die oben genannten Wege zur Skalierung.

Kann Locust auch andere Protokolle als HTTP testen?

Ja, wenn Sie einen Python-Client für das Protokoll mitbringen. Eingebaut sind nur HTTP und HTTPS.

Die Seite zu weiteren Protokollen zeigt, wie Sie einen Client so kapseln, dass jeder Aufruf erfasst wird, mit Beispielen für XML-RPC und gRPC und experimentellen User-Klassen für MQTT, Socket.IO und OpenAI. Das separate Projekt locust-plugins ergänzt User-Klassen für Kafka, FTP, Selenium und Playwright (geprüft am 9. Oktober 2026).

Für HTTP gibt es zusätzlich FastHttpUser, das geventhttpclient nutzt und deutlich weniger CPU braucht. Im besten Fall schafft ein Prozess laut Dokumentation etwa 16.000 Anfragen pro Sekunde, mit HttpUser 4.000. Einzelne Anfragen werden dadurch nicht schneller, und TLS-Zertifikate prüft FastHttpUser standardmäßig nicht.

Welche Berichte liefert Locust, und wie passt es in die CI?

Sie bekommen Live-Diagramme in der Web-UI und auf Wunsch Ergebnisdateien. In der CI beendet sich Locust mit Exit-Code 1, wenn mindestens eine Anfrage fehlgeschlagen ist.

Laut der Konfigurationsreferenz schreibt --csv Dateien für Statistik, Verlauf und Fehler, --html speichert einen Bericht, und --json gibt die Endstatistik aus. --otel exportiert an ein OpenTelemetry-Backend. Die Headless-Dokumentation zeigt einen Listener, der den Lauf anhand der Fehlerquote, der durchschnittlichen Antwortzeit oder des 95. Perzentils scheitern lässt, und unser Leitfaden zu Lasttests in GitHub Actions baut ihn in einen Workflow ein.

Was kann Locust gut, und wo liegen seine Grenzen?

Stark ist Locust bei Testlogik und bei vielen gleichzeitigen Benutzern, die meist warten. Schwächer ist es bei der Anfragerate pro Prozess und bei Protokollen, die Sie selbst anbinden müssen.

Weil Tests reines Python sind, funktionieren Schleifen, Verzweigungen, generierte Daten und Ihr eigener API-Client, und die Tests liegen in der Versionsverwaltung. Die Seite What is Locust schreibt, dass die geringen Kosten pro Benutzer gut zu stark parallelen Lasten passen, räumt aber ein, dass andere Tools auf derselben Hardware mehr Anfragen pro Sekunde schaffen können.

Grenzen, die die Dokumentation selbst nennt:

Ein Python-Prozess nutzt nur einen CPU-Kern.
Bibliotheken mit I/O in C blockieren den Prozess, sofern gevent sie nicht patchen kann.
HttpUser parst kein HTML und lädt keine Seitenressourcen.
Die Wartezeit kann keine Benutzer hinzufügen, um eine Anfragerate zu halten.

Welche anderen Python-Tools für Lasttests gibt es?

Locust ist die aktiv entwickelte Python-Engine. Molotov, die wichtigste Alternative, hat seit 2022 keine neue Version auf PyPI veröffentlicht, und Taurus führt Locust über einen seiner Executors aus.

Molotov ist ein Tool für Python 3.8+ auf Basis von asyncio und aiohttp; die neueste Version auf PyPI ist 2.6 vom 21. Oktober 2022, und der letzte Commit auf seinem Hauptzweig stammt vom November 2023 (geprüft am 21. Oktober 2026). Taurus führt ein Locustfile oder einfache, in YAML geschriebene GET- und POST-Anfragen über seinen Executor locust aus. Locust installieren Sie selbst, im verteilten Modus startet Taurus nur den Master, und die Einstellung throughput wirkt bei diesem Executor nicht (geprüft am 21. Oktober 2026).

Wann sollten Sie stattdessen k6, JMeter oder Gatling wählen?

Wählen Sie ein anderes Tool, wenn dessen Sprache, Protokolle oder Lastmodell besser zu Ihrem Team passen.

Unser Überblick über Open-Source-Lasttest-Tools stellt Locust neben fünf weitere.

Wählen Sie stattdessen k6, wenn Ihr Team JavaScript schreibt, Bestanden-Kriterien als Thresholds im Skript festlegen will oder ein offenes Lastmodell braucht, das die Arrival-Rate-Executors von k6 liefern (geprüft am 9. Oktober 2026). LoadFocus führt k6-Skripte aus 25 Cloud-Regionen aus, startet Arrival-Rate-Szenarien dort aber mit einer festen Zahl von Benutzern. Für eine gehaltene Anfragerate führen Sie sie mit k6 selbst aus.

Wählen Sie stattdessen JMeter, wenn Sie JDBC, JMS, LDAP oder FTP ab Werk brauchen, wie es das README aufführt, oder wenn Ihre Tester Tests in einer GUI bauen. Locust vs JMeter vergleicht die beiden ausführlich.

Wählen Sie stattdessen Gatling, wenn Ihr Team auf der JVM arbeitet und offene wie geschlossene Injektionsprofile in einer API haben möchte (geprüft am 9. Oktober 2026). Gatling vs JMeter geht darauf näher ein.

FAQ

Darf man Locust kostenlos kommerziell nutzen? Ja. Locust steht unter der MIT-Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt.

Welche Python-Version braucht Locust? Python 3.11 oder neuer, laut den PyPI-Metadaten. Installiert wird es mit pip install locust, oder Sie starten es mit uvx locust in einer temporären Umgebung.

Kann LoadFocus Locust-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um einen Locust-Test zu skalieren, nutzen Sie den Master-Worker-Modus, den Kubernetes-Operator oder Azure Load Testing.

Weiterlesen

Locust vs JMeter: Python-Skripte oder JMeter-Testpläne?

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Locust und Apache JMeter sind beide kostenlose Open-Source-Lasttest-Tools, und welches besser passt, hängt vor allem davon ab, wie Ihr Team Tests bauen möchte. Nehmen Sie Locust, wenn Ihr Team Python schreibt und Testlogik als gewöhnlichen Code haben will, ausgeführt von leichtgewichtigen, ereignisbasierten Benutzern. Nehmen Sie JMeter, wenn Sie Protokolle jenseits von HTTP wie JDBC, JMS oder LDAP brauchen, Tests lieber in einer GUI bauen oder bereits eine Sammlung von .jmx-Testplänen haben.

Die Fakten in diesem Vergleich Locust vs JMeter stammen aus der Dokumentation und den Repositories der beiden Projekte, geprüft am 9. Oktober 2026.

	Locust	Apache JMeter
Lizenz	MIT (Repository)	Apache 2.0 (Repository)
Laufzeit	Python 3.11 oder neuer	Java 8 oder neuer (Version 5.6.3)
Tests als	Python-Code in einem Locustfile	Testpläne aus einer GUI, gespeichert als XML-Dateien (`.jmx`)
GUI	Web-UI zum Starten, Anpassen und Beobachten eines laufenden Tests	Desktop-IDE zum Aufzeichnen, Bauen und Debuggen von Testplänen
Eingebaute Protokolle	HTTP und HTTPS; andere über einen Python-Client	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, Mail, TCP, Shell-Befehle, Java-Objekte
Virtuelle Benutzer	Ein Greenlet pro Benutzer auf gevent (ereignisbasiert)	Ein Java-Thread pro Benutzer
Verteilter Modus	Ein Master und beliebig viele Worker	Ein Client steuert entfernte JMeter-Server
CI und Headless-Läufe	`--headless`, Exit-Code 1 bei fehlgeschlagenen Anfragen	CLI-Modus (`jmeter -n`)
Berichte	Live-Diagramme in der Web-UI, CSV-Dateien, HTML-Bericht	HTML-Dashboard, Live-Ergebnisse über einen Backend Listener

Was ist der Unterschied zwischen Locust und JMeter?

In Locust ist ein Test ein Python-Programm. In JMeter ist ein Test ein Plan, den Sie in einer Desktop-GUI zusammenstellen und als Datei speichern, und daraus folgen die meisten anderen Unterschiede.

Das README von Locust beschreibt Tests, die mit ganz normalen Python-Schleifen, Bedingungen und Bibliotheken geschrieben werden. Installiert wird Locust mit pip install locust auf Python 3.11 oder neuer, so die Paket-Metadaten.

Ein JMeter-Test ist ein Baum aus Elementen: eine Thread Group für die Benutzer, Sampler für die Anfragen sowie Assertions und Listener für die Ergebnisse. JMeter 5.6.3, die aktuelle Version auf der Download-Seite, braucht Java 8 oder neuer. Das README im Entwicklungszweig von JMeter verlangt bereits Java 17 (geprüft am 10. Oktober 2026). Wenn ein Schritt echte Logik braucht, führt ein JSR223-Sampler ein Groovy-Skript innerhalb des Plans aus.

Wie schreibt man in beiden Tools einen Test?

In Locust schreiben Sie für jede Art von Benutzer eine Python-Klasse, deren Methoden als Tasks markiert sind. In JMeter fügen Sie in der GUI eine Thread Group und Sampler hinzu, speichern den Plan und starten ihn von der Kommandozeile.

Ein Locust-Benutzer, der zwischen den Tasks ein bis drei Sekunden wartet und die Benutzerliste dreimal so oft abruft wie einen einzelnen Benutzer:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def list_users(self):
        self.client.get("/api/users")

    @task
    def view_user(self):
        self.client.get("/api/users/42", name="/api/users/[id]")

Headless gestartet mit 50 Benutzern, fünf neuen pro Sekunde, für fünf Minuten:

locust -f locustfile.py --headless -u 50 -r 5 \
  --run-time 5m --host https://staging.example.com

In JMeter ist derselbe Test eine Thread Group mit 50 Threads und einer Ramp-up-Zeit, die zwei HTTP-Request-Sampler enthält. Die Einstiegsanleitung startet einen gespeicherten Plan im CLI-Modus, und -e -o erzeugt am Ende den HTML-Bericht:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Die .jmx-Datei ist XML, wie die mit JMeter ausgelieferten Beispiele zeigen, und lässt sich in einem Pull Request schwerer prüfen als Python. JMeter kann einen Plan außerdem im Browser aufzeichnen; das Gegenstück bei Locust ist har2locust, ein Konverter von HAR-Aufzeichnungen zu Locustfiles im Beta-Stadium (geprüft am 9. Oktober 2026).

Welche Protokolle kann jedes Tool testen?

JMeter deckt von Haus aus deutlich mehr Protokolle ab. Locust bringt HTTP und HTTPS mit und erwartet für alles andere einen Python-Client, den Sie selbst mitbringen.

Das README von JMeter nennt HTTP und HTTPS, SOAP und REST, FTP, Datenbanken über JDBC, LDAP, JMS-Messaging, Mail über SMTP, POP3 und IMAP, TCP, native Befehle und Java-Objekte. Für JDBC und JMS brauchen Sie die Treiber-JARs Ihres Datenbank- oder JMS-Anbieters.

Die Seite zu weiteren Protokollen in der Locust-Dokumentation zeigt, wie Sie eine Protokollbibliothek kapseln, mit Beispielen für gRPC, XML-RPC und MQTT, und verweist für Kafka, Selenium und Playwright auf locust-plugins (geprüft am 9. Oktober 2026). Die Bibliothek muss mit gevent zusammenarbeiten, denn I/O in kompiliertem C-Code blockiert den ganzen Prozess; die Dokumentation nennt als Beispiel den PostgreSQL-Treiber psycopg2, der ein Zusatzpaket braucht. Für Lasttests gegen Datenbanken ist der JDBC-Sampler von JMeter der kürzere Weg.

Wie funktionieren virtuelle Benutzer in Locust und JMeter?

JMeter führt jeden virtuellen Benutzer als Java-Thread aus. Locust führt jeden Benutzer als Greenlet in der Event-Loop von gevent aus, was die Kosten pro Benutzer niedrig hält.

Jeder Thread in einer JMeter-Thread Group arbeitet den ganzen Plan unabhängig ab. JMeter startet standardmäßig mit 1 GB Heap, was laut Anleitung für größere Pläne und viele Threads nicht reichen kann.

Laut README kann ein einzelner Locust-Prozess viele Tausend gleichzeitige Benutzer bedienen. Die Dokumentation zur verteilten Last ergänzt, dass ein Python-Prozess nicht mehr als einen CPU-Kern voll ausnutzen kann. Sie starten deshalb einen Worker pro Kern, was --processes auf einem einzelnen Rechner für Sie erledigt.

Wie verteilt man einen Test auf mehrere Rechner?

Beide haben einen verteilten Modus eingebaut. Bei Locust steuert ein Master die Worker, die die Benutzer ausführen, und bei JMeter startet der Client den vollständigen Testplan auf jedem entfernten Server.

In Locust führt ein mit --master gestarteter Prozess die Web-UI aus und sagt den --worker-Prozessen, wann sie Benutzer starten und stoppen. Die Locust-Dokumentation beschreibt außerdem einen Kubernetes-Operator und Azure Load Testing, einen Microsoft-Dienst, der Locust-Tests in der Cloud ausführt (geprüft am 9. Oktober 2026).

Im Remote-Testmodus von JMeter steuert ein Client beliebig viele Server über RMI. Jeder Server führt den ganzen Plan aus, aus 1.000 Threads auf sechs Servern werden also 6.000 Threads. Alle Knoten sollten dieselbe JMeter- und Java-Version verwenden, RMI braucht einen Keystore, sofern SSL nicht deaktiviert ist, und Datendateien müssen Sie auf jeden Server kopieren.

Für JMeter-Testpläne gibt es einen dritten Weg. LoadFocus, der Herausgeber dieser Website, führt vorhandene JMeter-Testpläne unverändert aus 25 Cloud-Regionen aus, ganz ohne Remote-Server, die Sie einrichten müssten. Locust-Tests führt LoadFocus nicht aus, für Locust bleiben also die oben genannten Wege zur Skalierung.

Wie passen beide in die CI, und welche Berichte bekommen Sie?

Beide laufen headless von der Kommandozeile. Locust beendet sich zusätzlich mit Exit-Code 1, wenn Anfragen fehlschlagen, und JMeter liefert den umfangreicheren HTML-Bericht.

Die Headless-Dokumentation von Locust zeigt einen kurzen Event-Listener, der den Exit-Code anhand der Fehlerquote, der durchschnittlichen Antwortzeit oder des 95. Perzentils setzt, dazu ein Beispiel für GitHub Actions. Mit den Optionen --csv und --html speichert Locust nach dem Lauf Ergebnisse und einen Bericht.

Die JMeter-Dokumentation ist eindeutig: Lasttests laufen im CLI-Modus, die GUI ist zum Bauen und Debuggen da. Das README verweist für Maven, Gradle und Jenkins auf Bibliotheken von Drittanbietern. Das JMeter-Dashboard enthält eine APDEX-Tabelle, eine Statistiktabelle mit drei konfigurierbaren Perzentilen, Fehlerübersichten und Diagramme der Antwortzeit.

Welches Tool sollten Sie wählen?

Wählen Sie Locust, wenn Ihr Team Python schreibt und Lasttests wie den übrigen Code im Review prüfen will. Wählen Sie stattdessen JMeter, wenn Sie Protokolle jenseits von HTTP brauchen, wenn Ihre Tester lieber mit einer GUI arbeiten oder wenn Sie bereits .jmx-Pläne haben.

Locust passt zu Szenarien mit Schleifen, Verzweigungen und generierten Daten, zu Tests, die einen internen Python-Client für Ihre API wiederverwenden, und zu hoher Parallelität mit Benutzern, die die meiste Zeit warten.

JMeter ist die bessere Wahl für Tests mit JDBC, JMS, LDAP, FTP oder Mail, für die Locust einen selbst gepflegten Client bräuchte, und für Tester, die einen Ablauf im Browser aufzeichnen und visuell verfeinern. Ein Unternehmen, das JMeter bereits nutzt, behält außerdem seine Pläne und sein Know-how.

FAQ

Ist Locust schneller als JMeter? Das haben wir nicht selbst gemessen, deshalb nennen wir keinen Sieger. Fair vergleichen lässt sich das nur mit demselben Szenario in beiden Tools auf Ihrer eigenen Hardware.

Kann Locust JMeter-Dateien im .jmx-Format ausführen? Laut seiner Dokumentation nicht, denn sie beschreibt Tests ausschließlich als Python-Locustfiles. Wer einen JMeter-Testplan nach Locust überträgt, schreibt ihn in Python neu.

Kann LoadFocus Locust-Tests ausführen? Nein. LoadFocus führt JMeter- und k6-Skripte aus. Um einen Locust-Test über einen Rechner hinaus zu skalieren, nutzen Sie den Master-Worker-Modus von Locust, seinen Kubernetes-Operator oder Azure Load Testing.

Weiterlesen

Offenes vs geschlossenes Lastmodell: welches passt wann?

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Bei der Frage offenes vs geschlossenes Lastmodell zählt vor allem, wie Nutzer Ihr System erreichen. Ein offenes Modell startet neue Iterationen mit einer festen Ankunftsrate und passt zu öffentlichen Websites und APIs, deren Nutzer weiterhin kommen, egal wie langsam das System antwortet; ein geschlossenes Modell, also eine feste Zahl virtueller Benutzer, die jeweils auf das Ende ihrer letzten Iteration warten, passt nur dort, wo das System selbst die Parallelität begrenzt. Am stärksten wirkt die Wahl unter Sättigung: Dann bremst ein geschlossener Test seine eigene Last und lässt das System gesünder aussehen, als es ist.

Die Fakten zu den Tools stammen aus der Dokumentation der jeweiligen Projekte, geprüft am 9. Oktober 2026.

	Offenes Modell	Geschlossenes Modell
Sie legen fest	Neue Iterationen oder Nutzer pro Sekunde	Gleichzeitige virtuelle Benutzer
Wenn Antworten langsamer werden	Arbeit kommt weiter an, Warteschlangen wachsen	Nutzer warten, es wird weniger Last erzeugt
Reale Systeme dieser Art	Die meisten öffentlichen Websites und APIs	Callcenter, Ticket-Warteschlangen, Worker-Pools
k6	`constant-arrival-rate`, `ramping-arrival-rate`	`constant-vus`, `ramping-vus`
Gatling	`injectOpen`	`injectClosed`
Locust	Angenähert mit `constant_throughput` oder `poisson`	Nutzer mit einer `wait_time`
JMeter	Open Model Thread Group, Arrivals-Plugin	Thread Group

Was ist der Unterschied zwischen einem offenen und einem geschlossenen Lastmodell?

Im offenen Modell bestimmt der Lastgenerator, wann Arbeit ankommt, im geschlossenen Modell die Antwortzeit des Systems.

Die k6-Dokumentation sagt es deutlich: Im geschlossenen Modell startet die nächste Iteration eines virtuellen Benutzers erst, wenn die letzte beendet ist, während im offenen Modell neue Iterationen unabhängig davon ankommen, ob die vorherigen fertig sind (geprüft am 9. Oktober 2026). Ein geschlossener Test mit 50 virtuellen Benutzern hat nie mehr als 50 Iterationen gleichzeitig in Arbeit. Ein offener Test mit 50 Iterationen pro Sekunde startet jede Sekunde weitere 50, und wenn jede länger dauert, überlappen sich mehr davon.

Warum verbirgt ein geschlossenes Modell Latenz, wenn das System gesättigt ist?

Weil der Test zusammen mit dem System langsamer wird. Wenn Antworten länger dauern, sendet jeder Nutzer im geschlossenen Modell weniger Anfragen, und die Last sinkt genau dann, wenn Sie sie steigen sehen wollten.

Die k6-Dokumentation beschreibt den Effekt: Langsamere Antworten bedeuten längere Iterationen und eine niedrigere Ankunftsrate neuer Iterationen. Gatlings Seite zu Lastmodellen geht weiter und nennt ein geschlossenes Modell gegen ein eigentlich offenes System einen kaputten Test, der ein imaginäres Verhalten prüft (geprüft am 9. Oktober 2026).

Ein geschlossener Test zeigt deshalb Antwortzeiten, die sich einpendeln, weil nie mehr Anfragen unterwegs sein können, als es Nutzer gibt. Ein offener Test zeigt die wachsende Warteschlange, mit Antwortzeiten, die steigen, solange mehr ankommt, als das System abarbeitet. Das zweite Bild ist das, was Ihre Nutzer erleben würden, und die p95- und p99-Antwortzeiten, die Sie am Ende ablesen, sind nur so ehrlich wie das Lastmodell dahinter.

Die k6-Dokumentation merkt an, dass ein Teil der Fachliteratur dieses Problem Coordinated Omission nennt. Ein USENIX-Paper von 2006, auf das die Gatling-Dokumentation verweist, Open Versus Closed: A Cautionary Tale, kam zu dem Ergebnis, dass beide Modelle selbst bei gleicher Last und gleichen Bedienanforderungen deutlich unterschiedliche Ergebnisse liefern.

Welches Modell passt zu Ihrem echten Traffic?

Wählen Sie ein offenes Modell für alles, was öffentlich erreichbar ist, und ein geschlossenes nur dort, wo das System selbst begrenzt, wie viele Nutzer gleichzeitig aktiv sind.

Die Gatling-Dokumentation nennt Callcenter, in denen alle Mitarbeitenden beschäftigt sind, und Ticketing-Websites, die Nutzer bei voller Auslastung in eine Warteschlange stellen, als geschlossene Systeme und sagt, dass sich die meisten Websites offen verhalten. Ein Batch-Job mit fester Zahl an Workern oder ein Queue-Consumer mit festgelegter Parallelität ist ebenfalls geschlossen. Öffentliche APIs, Webseiten und Webhooks sind offen: Nichts hält die nächste Anfrage zurück, nur weil die letzte langsam war.

Viele Systeme liegen dazwischen: Eine Käuferin kommt nach ihrem eigenen Zeitplan, wartet dann aber innerhalb des Besuchs auf jede Seite. Das Paper oben nennt das ein teilweise offenes Modell. In k6 oder Gatling legen Sie dafür die Ankunftsrate der Sitzungen fest und machen jede Iteration zu einer vollständigen Nutzerreise mit eigenen Pausen.

Wie stellt man in k6 jedes Modell ein?

Über den Executor. constant-vus und ramping-vus ergeben ein geschlossenes Modell, constant-arrival-rate und ramping-arrival-rate ein offenes.

Ein geschlossenes Szenario setzt executor: "constant-vus" mit einer Zahl vus und einer duration. Ein offenes Szenario legt stattdessen eine Rate fest, und Sie reservieren vorab genug virtuelle Benutzer, um sie zu halten:

export const options = {
  scenarios: {
    open_model: {
      executor: "constant-arrival-rate",
      rate: 50,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 100,
    },
  },
  thresholds: {
    dropped_iterations: ["count<10"],
  },
};

k6 startet eine Iteration nur, solange ein virtueller Benutzer frei ist, und die Dokumentation rät davon ab, sich auf maxVUs zu verlassen, weil zusätzliche Nutzer mitten im Test den Lastgenerator überlasten können. Ist kein Nutzer frei, verbucht k6 eine verworfene Iteration, was spät im Test oft heißt, dass das System langsamer wird; der Schwellenwert oben lässt den Lauf bei zehn davon scheitern. Setzen Sie kein sleep() ans Ende einer Arrival-Rate-Iteration, denn der Executor taktet die Starts bereits (geprüft am 9. Oktober 2026).

Wenn Sie k6-Skripte auf LoadFocus ausführen, nimmt sein k6-Cloud-Runner die Last aus den Einstellungen des Tests, und sein Skript-Validator warnt, dass Arrival-Rate-Szenarien dort mit einer festen Nutzerzahl laufen, die Anfragerate also nicht gehalten wird. Für einen echten Test im offenen Modell führen Sie die Arrival-Rate-Executors mit k6 selbst aus oder bei einem Dienst, der sie so ausführt, wie sie geschrieben sind.

Wie bilden Gatling, Locust und JMeter die beiden Modelle ab?

Gatling trennt die beiden Modelle in seiner API, JMeter bietet beide über unterschiedliche Thread Groups, und Locust ist um eine feste Zahl von Nutzern herum gebaut.

Gatling. Ein Szenario nutzt entweder injectOpen oder injectClosed. Offene Schritte wie constantUsersPerSec und rampUsersPerSec legen Ankunftsraten fest, geschlossene wie constantConcurrentUsers und rampConcurrentUsers die Parallelität. Ein Injektionsprofil kann die beiden nicht mischen (geprüft am 9. Oktober 2026).

Locust. Sie legen eine Zahl von Nutzern fest, und die wait_time jedes Nutzers steuert die Pause zwischen Tasks. constant_throughput und constant_pacing passen diese Pause so an, dass jeder Nutzer höchstens eine bestimmte Zahl von Tasks pro Sekunde ausführt, doch laut Dokumentation kann die Wartezeit den Durchsatz nur begrenzen und keine neuen Nutzer starten, um ein Ziel zu erreichen. poisson() wählt die Pausen zufällig, was laut Dokumentation echten Ankünften näherkommt. Das Beispiel der Dokumentation für 500 Task-Iterationen pro Sekunde ist constant_throughput(0.1) mit 5.000 Nutzern, ein geschlossener Pool mit viel Reserve (geprüft am 9. Oktober 2026).

JMeter. Die klassische Thread Group ist ein geschlossener Pool von Threads. Der Constant Throughput Timer und der Precise Throughput Timer takten diesen Pool auf eine Rate hin, und die Referenz warnt, dass der Durchsatz sinkt, wenn der Server nicht mithält oder es zu wenige Threads gibt. Für Ankünfte hat JMeter 5.5 die Open Model Thread Group eingeführt, weiterhin als experimentell markiert, mit Zeitplänen wie rate(10/sec) random_arrivals(1 min). Das Community-Plugin Arrivals Thread Group startet neue Threads, wenn alle vorhandenen beschäftigt sind, mit einem Concurrency-Limit als Sicherheitsventil (geprüft am 9. Oktober 2026).

Worauf sollten Sie bei einem Test im offenen Modell achten?

Beobachten Sie den Lastgenerator so genau wie das System unter Test. Im offenen Modell bedeutet ein langsames System mehr gleichzeitige Nutzer auf Ihrer Seite, und die kosten Speicher und CPU.

Setzen Sie eine Obergrenze, etwa maxVUs in k6 oder das Concurrency-Limit des JMeter-Plugins, und werten Sie das Erreichen dieser Grenze als Ergebnis: Das System konnte die verlangte Rate nicht aufnehmen.

FAQ

Ist ein geschlossenes Lastmodell jemals die richtige Wahl? Ja. Nutzen Sie es, wenn das reale System die Parallelität begrenzt, etwa bei einem festen Pool von Workern, einem Queue-Consumer oder einem Callcenter, oder wenn Sie wissen wollen, wie viele gleichzeitige Sitzungen eine Komponente verkraftet. Für öffentlichen Web-Traffic passt ein offenes Modell besser.

Macht Think Time aus einem geschlossenen Modell ein offenes? Nein. Think Time senkt, wie oft jeder Nutzer Anfragen sendet, aber jeder Nutzer wartet weiterhin auf die vorherige Antwort, also bremst ein langsames System den Test trotzdem. Nur eine Ankunftsrate, die unabhängig von den Antwortzeiten festgelegt ist, ergibt ein offenes Modell.

Wie viele virtuelle Benutzer braucht ein Arrival-Rate-Test? Genug, um jede gleichzeitig laufende Iteration abzudecken. Die k6-Dokumentation schlägt den Median der Iterationsdauer mal Zielrate vor, plus eine Reserve für Schwankungen, ermittelt in kurzen Probeläufen vor dem eigentlichen Test.

Weiterlesen

Think Time im Lasttest: was sie ist und wie man sie wählt

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Think Time im Lasttest ist die Pause, die ein virtueller Benutzer zwischen zwei Aktionen einlegt, stellvertretend für die Sekunden, in denen ein echter Mensch eine Seite liest oder ein Formular ausfüllt. Sie bestimmt, wie viel Last jeder virtuelle Benutzer erzeugt: Je länger die Pause, desto weniger Anfragen pro Sekunde schickt dieselbe Zahl von Benutzern. Messen Sie sie an echten Nutzerdaten, streuen Sie sie zufällig um diesen Wert und schreiben Sie sie mit dem Pausenbefehl Ihres Tools ins Skript.

Think Time pro Durchlauf	Ein Durchlauf dauert	Anfragen pro Sekunde bei 100 Benutzern
0 s	0,5 s	200
1 s	1,5 s	etwa 67
3 s	3,5 s	etwa 29
5 s	5,5 s	etwa 18
10 s	10,5 s	etwa 10

Das ist reine Rechnung ohne Testlauf dahinter: eine Anfrage pro Durchlauf, 0,5 Sekunden Antwortzeit, und Benutzer geteilt durch (Antwortzeit + Think Time).

Was ist Think Time im Lasttest?

Think Time ist die bewusste Wartezeit, die ein Testskript zwischen die Schritte einer Nutzerreise setzt. Sie bildet den menschlichen Teil einer Sitzung ab: lesen, vergleichen, tippen.

In einem Shop-Skript liegt sie zwischen „Produktseite öffnen“ und „in den Warenkorb legen“, außerhalb jeder Anfrage. Der Leitfaden von LoadFocus zu Verzögerungen im Lasttest trennt sie von der Ramp-up-Verzögerung, die Benutzer schrittweise hinzufügt, und der Startverzögerung zwischen dem Start einzelner Benutzer, und merkt an, dass viele Tools mit dem bloßen Wort „Delay“ die Ramp-up-Variante meinen. Wenn ein Tool ein Feld „Delay“ anbietet, prüfen Sie, welche der drei gemeint ist.

Warum ändert Think Time die Last bei gleicher Benutzerzahl?

Bei einer festen Zahl virtueller Benutzer wartet jeder auf eine Antwort, pausiert und schickt erst dann die nächste Anfrage. Sein Durchlauf dauert Antwortzeit plus Think Time, also senkt jede zusätzliche Sekunde Think Time die Anfragen, die jeder Benutzer pro Sekunde schickt.

Hundert Benutzer ohne Pause schicken bei 0,5 Sekunden Antwortzeit 200 Anfragen pro Sekunde; mit 5 Sekunden Pause sind es etwa 18, zwei Läufe „mit 100 Benutzern“ können also sehr verschiedene Tests sein. Die k6-Dokumentation beschreibt denselben Effekt für ihr geschlossenes Modell: Die nächste Iteration beginnt erst, wenn die vorige fertig ist, also senken langsamere Antworten die Rate zusätzlich (geprüft am 9. Oktober 2026).

Think Time zu kürzen, um mit weniger Benutzern mehr Last zu erzeugen, hat seinen Preis: Zwanzig Benutzer ohne Pausen erreichen womöglich die Anfragerate von mehreren hundert Benutzern mit Pausen, halten dabei aber weit weniger Sitzungen und Verbindungen offen als die Produktion.

Was ist der Unterschied zwischen Think Time und Pacing?

Think Time ist eine Pause nach einem Schritt, ein Durchlauf wird also länger, sobald Antworten langsamer werden. Pacing legt den Abstand vom Start eines Durchlaufs bis zum Start des nächsten fest und verkürzt die Wartezeit, wenn die Arbeit länger gedauert hat.

Mit 30 Sekunden Pacing startet ein Benutzer alle 30 Sekunden einen Durchlauf, egal ob seine Anfragen 2 oder 20 Sekunden gebraucht haben. Das passt zu Tests, die aus Geschäftsvolumen abgeleitet sind, etwa „500 Bestellungen pro Stunde“. Die Dokumentation zu Locusts constant_pacing nennt den Grenzfall: Läuft die Aufgabe länger als das Intervall, fällt die Wartezeit auf null (geprüft am 9. Oktober 2026). Viele Skripte nutzen beides, Think Time zwischen den Schritten und Pacing für den ganzen Durchlauf.

Sollte Think Time fest oder zufällig sein?

Zufällig, um einen gemessenen Mittelwert herum. Eine feste Pause hält Benutzer, die gemeinsam gestartet sind, im Gleichschritt, sodass sie Durchlauf für Durchlauf im selben Moment dieselbe Seite aufrufen.

Diese synchronen Wellen können Spitzen erzeugen, die es in der Produktion nie gibt, und eine zufällige Pause verteilt die Benutzer. Halten Sie den Mittelwert dort, wo Ihre Daten ihn verorten: Eine gleichverteilte Pause zwischen 2 und 8 Sekunden ergibt im Mittel 5, also dieselbe mittlere Last wie eine feste Pause von 5 Sekunden. Gleichverteilung ist der einfache Standard; eine Normalverteilung (Gauß) bündelt Pausen um einen typischen Wert, eine Exponentialverteilung liefert viele kurze und wenige lange Wartezeiten.

Wie wählt man Werte für die Think Time?

Leiten Sie sie aus dem ab, was echte Nutzer bei jedem Schritt tun, mit Web-Analytics, Zugriffslogs oder Real-User-Monitoring. Nehmen Sie pro Schritt einen eigenen Wert, denn eine Produktseite zu lesen dauert länger, als einen Knopf zu drücken.

Die Verweildauer auf einer Seite in Analytics oder der Abstand zwischen aufeinanderfolgenden Anfragen einer Sitzung in den Zugriffslogs kommt der Think Time für diesen Schritt nahe. Nehmen Sie den Median als mittlere Pause und die Streuung für den Zufallsbereich, und lassen Sie Leerlauf wie einen über Mittag offenen Tab weg.

Eine API, die von anderen Programmen aufgerufen wird, hat keinen Menschen in der Schleife, also modellieren Sie direkt ihre Anfragerate. Ohne Daten schreiben Sie die angenommenen Werte in den Testplan, damit ein späterer Lauf sie ersetzen kann; die Schritt-für-Schritt-Anleitung zum Lasttest zeigt, wo sie hingehören.

Wie fügt man Think Time in k6, JMeter, Gatling, Locust und Artillery ein?

Jedes Tool hat einen eigenen Pausenbefehl, und die meisten bieten zusätzlich Pacing oder eine Ratensteuerung.

Tool	Feste Pause	Zufällige Pause	Pacing oder Rate
k6	`sleep(3)`	`sleep(2 + Math.random() * 6)`	Arrival-Rate-Executors
JMeter	Constant Timer	Uniform oder Gaussian Random Timer	Constant Throughput Timer
Gatling	`pause(3)`	`pause(2, 8)`	`pace(30)`
Locust	`constant(3)`	`between(2, 8)`	`constant_pacing`
Artillery	`think: 3`	`think` + `jitter` (in `config.http.defaults`)	Ankunftsrate pro Phase

Die Tabelle oben und die Hinweise unten stammen aus der Dokumentation der Projekte, geprüft am 9. Oktober 2026; alle fünf Tools kommen in unserem Überblick über Open-Source-Lasttest-Tools vor.

k6. sleep(t) pausiert den virtuellen Benutzer für t Sekunden; die Dokumentation baut zufällige Pausen mit Math.random() oder mit randomIntBetween() aus k6-utils:

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // 2 bis 8 Sekunden
  http.get("https://example.com/cart");
}

JMeter. Unter den Timern nimmt der Constant Timer eine Verzögerung in Millisekunden, Uniform und Gaussian Random Timer addieren einen Zufallsanteil zu einem festen Offset, und der Constant Throughput Timer variiert seine Pausen, um ein Ziel an Samples pro Minute zu halten. Ein Timer läuft vor jedem Sampler in seinem Gültigkeitsbereich, ein einzelner Timer auf Ebene der Thread Group pausiert also vor jeder Anfrage.

Gatling. pause(2, 8) wartet eine gleichverteilte Zufallszeit, und pace(30) in einer Schleife lässt sie höchstens einmal alle 30 Sekunden laufen. Auf Simulationsebene können Sie alle Pausen auf eine Normal- oder Exponentialverteilung umstellen oder sie mit disablePauses() abschalten.

Locust. wait_time greift nach jeder Aufgabe, eine Aufgabe mit zwei Anfragen unter constant_throughput(2) schickt also vier Anfragen pro Sekunde und Benutzer.

Artillery. Ein think-Schritt pausiert für eine Anzahl Sekunden, und eine think.jitter-Einstellung unter config.http.defaults streut jeden think-Schritt zufällig. Zwei dieser Tools im direkten Vergleich: k6 vs Artillery.

Spielt Think Time in einem Arrival-Rate-Test eine Rolle?

Für die Anfragerate eine kleinere als bei fester Benutzerzahl. Wenn das Tool neue Iterationen mit fester Rate startet, bestimmen Pausen, wie lange jeder Benutzer bleibt und damit, wie viele gleichzeitig aktiv sind.

Die Arrival-Rate-Executors von k6 takten Iterationen über ihre Rate, und die Dokumentation rät von einem sleep am Ende der Iteration ab; die Lastphasen von Artillery erzeugen ebenso eine feste Zahl neuer virtueller Benutzer pro Sekunde (beides geprüft am 9. Oktober 2026). Think Time zwischen den Schritten prägt trotzdem jede Sitzung.

Wie setzen die Skript-Werkzeuge von LoadFocus Think Time?

Sie schreiben sie als Startwert in das k6- oder JMeter-Skript, den Sie anschließend anpassen.

Der Import aus cURL, HAR, Postman oder OpenAPI macht aus einer aufgezeichneten Anfrage ein k6-Skript, das jede Iteration mit sleep(1) beendet; behandeln Sie diese Sekunde als Platzhalter für Ihre gemessenen Werte. Der KI-Testgenerator von LoadFocus hat die Anweisung, jedem Schritt eine Think Time zu geben, schreibt sie als sleep() für k6 oder als Constant Timer für JMeter und warnt, wenn ein Szenario mit mehreren Schritten keine hat.

FAQ

Kann man einen Lasttest ohne Think Time fahren? Ja, um den maximalen Durchsatz eines Endpunkts zu finden oder für einen Stresstest, sofern Sie das Ergebnis als Anfragen pro Sekunde angeben. Über die Zahl echter Nutzer, die das System bedienen kann, sagt es wenig.

Zählt Think Time zur Antwortzeit? Nicht bei den Zeiten einzelner Anfragen. In k6 umfasst http_req_duration Senden, Warten und Empfangen, während iteration_duration den ganzen Durchlauf abdeckt (Metrik-Referenz, geprüft am 9. Oktober 2026). Ein Transaction Controller in JMeter lässt Timer aus seiner Zeit heraus, außer Sie aktivieren die Option, die sie einschließt.

Weiterlesen

WebSocket-Lasttest-Tools: sechs Optionen im Vergleich

Fri, 09 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

WebSocket-Lasttest-Tools mit eingebauter Unterstützung sind k6, Artillery, Gatling und Tsung, während JMeter das Plugin WebSocket Samplers braucht und Locust eigenen Client-Code oder seinen experimentellen Socket.IO-User. Wählen Sie nach der Sprache, in der Ihr Team schreibt, und danach, wie genau Sie die Nachrichten prüfen müssen, die der Server zurückschickt.

Für diesen Artikel haben wir die Tools nicht gegen einen WebSocket-Server laufen lassen. Die Fakten stammen aus der Dokumentation und den Repositories der Projekte, geprüft am 9. Oktober 2026, und die Hinweise „Wählen Sie stattdessen“ sind unsere Einschätzung.

Tool	WebSocket-Unterstützung	Tests geschrieben in	Prüfen, was der Server sendet
k6	Eingebaut: `k6/websockets`, älter `k6/ws`	JavaScript	Event-Handler in Ihrem Skript
Artillery	Eingebaute Engines `ws` und `socketio`	YAML, dazu JavaScript-Funktionen	Socket.IO-Antworten und Acknowledgements
Gatling	Teil des HTTP-SDK	Java, Kotlin, Scala, JavaScript	Checks, die auf eine erwartete Nachricht warten
Apache JMeter	Plugin WebSocket Samplers	In der GUI gebaute Testpläne	Request-Response- und Lese-Sampler
Locust	Eigener Client oder der experimentelle `SocketIOUser`	Python	Was Ihr Code meldet
Tsung	Eingebauter Sitzungstyp `ts_websocket`	XML	`ack` wartet auf eine Serverantwort

Was unterscheidet WebSocket-Last von HTTP-Last?

Ein WebSocket-Benutzer öffnet eine Verbindung und hält sie die ganze Sitzung über, und der Server kann jederzeit Nachrichten senden. Ein Test hat deshalb zwei Stellschrauben, offene Verbindungen und Nachrichten pro Sekunde, und jede belastet den Server auf eigene Weise.

Der WebSocket-Leitfaden von k6 beschreibt Vollduplex-Verkehr über eine einzige TCP-Verbindung und erklärt, dass ein virtueller Benutzer dabei eine Event-Loop ausführt, solange der Socket offen ist, und die Hauptfunktion nicht mehr in Schleife durchläuft. Die WebSocket-Referenz von Gatling ergänzt, dass der Verkehr in beide Richtungen fließt, sodass das HTTP-Modell aus Anfrage und Antwort nicht mehr passt.

Planen Sie drei Arten von Tests. Viele untätige Verbindungen zeigen, wie viele Sockets Ihre Server halten können. Eine kleinere Gruppe gesprächiger Clients prüft die Nachrichtenverarbeitung. Ein Broadcast, bei dem eine Nachricht an alle Abonnenten geht, prüft den Push-Pfad.

Was sollten Sie in einem WebSocket-Lasttest messen?

Messen Sie Verbindungsaufbauzeit, Nachrichtenlatenz und abgebrochene Verbindungen, dazu, wie viele Verbindungen offen bleiben. Diese Werte zeigen, was Nutzer einer Echtzeit-App spüren.

Zu den eingebauten Metriken von k6 gehören ws_connecting, ws_ping, ws_session_duration, ws_sessions und Nachrichtenzähler. Keine davon misst eine Anwendungsnachricht, für die Zeit zwischen der Nachricht eines Clients und der Antwort des Servers brauchen Sie also eine eigene Trend-Metrik. Die ws-Engine von Artillery meldet Nachrichtenzähler und -raten, und ihre Socket.IO-Engine ergänzt socketio.response_time, die Zeit vom Senden einer Nachricht bis zur Antwort.

Für abgebrochene Verbindungen zählen Sie Close- und Error-Events, die Ihr Skript nicht selbst ausgelöst hat, und vergleichen die gestarteten Sitzungen mit denen, die am Ende jeder Stufe noch offen sind.

Wann ist k6 das richtige WebSocket-Tool?

Wenn Ihr Team JavaScript schreibt und jeder virtuelle Benutzer mehrere Sockets gleichzeitig halten soll. k6 bringt WebSocket-Unterstützung von Haus aus mit, ohne Erweiterung.

Das Modul k6/websockets folgt der WebSocket-API des Browsers und nutzt eine globale Event-Loop, mit der ein virtueller Benutzer mehrere Verbindungen offen halten kann. Das ältere Modul k6/ws ist weiter dokumentiert, k6 empfiehlt für neue Tests aber k6/websockets, und k6/experimental/websockets ist veraltet.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Thresholds funktionieren auch mit eigenen Metriken, ein verfehltes Latenzziel liefert der CI also einen Exit-Code ungleich null. Wählen Sie stattdessen Artillery, wenn Ihr Server Socket.IO spricht und Sie Emits und Acknowledgements ohne eigenen Client-Code prüfen wollen. Die weiteren Unterschiede behandelt unser Vergleich k6 vs Artillery.

Wann passt Artillery?

Wenn Sie kurze YAML-Szenarien wollen oder Ihr Server Socket.IO nutzt. Beide Engines sind in Artillery selbst enthalten.

Ein Szenario auf der WebSocket-Engine besteht aus fünf Aktionen: connect, send, think, loop und function. Die Socket.IO-Engine geht weiter: Ein emit kann die erwartete Antwort angeben, ein Acknowledgement per JSONPath-Abgleich prüfen und sich ein Szenario mit HTTP-Anfragen teilen, was zu Apps passt, die sich per HTTP anmelden, bevor sie einen Socket öffnen.

Wählen Sie stattdessen k6 oder Gatling, wenn ein Test prüfen muss, was ein reiner WebSocket-Server zurückschickt, denn die Dokumentation der ws-Engine beschreibt keinen Schritt, der auf eine Antwort wartet oder sie abgleicht.

Für wen ist Gatling bei WebSockets gedacht?

Für Teams auf der JVM oder mit dem JavaScript-SDK von Gatling, die Prüfungen von Nachrichten direkt ins Szenario schreiben wollen. WebSocket-Unterstützung ist Teil des HTTP-SDK von Gatling, HTTP- und WebSocket-Schritte teilen sich also eine Simulation.

Die Referenz behandelt connect, sendText, sendBytes und close sowie Checks, die blockieren, bis die erwartete Nachricht eintrifft oder ein Timeout abläuft. Über Protokolleinstellungen lassen sich vom Server geschlossene Sockets neu verbinden, ausgewählte Textnachrichten wie ein Ping automatisch beantworten und Nachrichten puffern, auf die kein Check gepasst hat. Laut Repository gehört WebSocket ohne Einschränkungen zur Community-Edition unter Apache 2.0.

Wählen Sie stattdessen k6, wenn Sie auf gepushte Nachrichten lieber in Event-Handlern reagieren als mit blockierenden Checks.

Kann JMeter WebSockets lasttesten?

Ja, mit einem Plugin. JMeter selbst hat keinen WebSocket-Sampler, die übliche Erweiterung ist WebSocket Samplers von Peter Doornbosch.

Die Komponentenreferenz von JMeter erwähnt WebSocket überhaupt nicht. Das Repository des Plugins beschreibt sechs Sampler: Verbindung öffnen, Request-Response, Ping-Pong, einzelnes Lesen, einzelnes Schreiben und Schließen. Sie laufen im Thread der Thread-Gruppe, unterstützen wss und Binärframes und können Frames herausfiltern, die für einen Test keine Rolle spielen. Installiert wird es über den Plugins Manager oder als JAR in lib/ext; Version 1.3.2 wurde im Januar 2026 getaggt (geprüft am 9. Oktober 2026).

Wählen Sie ein anderes Tool, wenn Sie kein Drittanbieter-Plugin auf jedem Lastgenerator pflegen möchten.

Was ist mit Locust und Tsung?

Locust erreicht reine WebSockets nur über Client-Code, den Sie selbst ergänzen, und Tsung unterstützt sie in seiner XML-Konfiguration, veröffentlicht aber selten neue Versionen. Beides funktioniert, mit mehr Aufwand.

Laut der Dokumentation von Locust unterstützt das Tool von Haus aus nur HTTP und HTTPS; andere Protokolle kommen hinzu, indem Sie eine Client-Bibliothek kapseln und nach jedem Aufruf das Event request auslösen. Die Bibliothek muss sich von gevent patchen lassen, sonst blockiert sie den ganzen Prozess. Für Socket.IO gibt es einen experimentellen SocketIOUser. Wählen Sie Locust, wenn Ihr Team Python schreibt und diesen Client-Code gern selbst pflegt.

Tsung ist ein Erlang-Projekt, das sich als verteiltes Lasttest-Tool für mehrere Protokolle beschreibt. Seine Sitzungsdokumentation definiert für WebSocket die Anfragen connect, message und close, mit einem Attribut ack, um auf eine Antwort zu warten. Die letzte getaggte Version, 1.8.0, stammt vom März 2023.

Wo passt ein gehosteter Runner wie LoadFocus hinein?

Viele offene Sockets von eigenen Rechnern zu halten, macht Arbeit, und ein gehosteter Runner übernimmt die Lasterzeugung. Am besten passt das, wenn Ihre Tests schon k6-Skripte sind.

LoadFocus, der Herausgeber dieser Website, führt k6-Skripte aus 25 Cloud-Regionen aus, und seine k6-Seite nennt WebSocket-Verbindungen unter den unterstützten k6-Funktionen. Außerdem gibt es eine Vorlage für WebSocket-Tests mit Ramp-up und Ramp-down (auf Englisch). Ob LoadFocus JMeter-Plugins wie WebSocket Samplers ausführt, haben wir nicht geprüft, dazu machen wir also keine Aussage.

Wie wählt man zwischen ihnen?

Gehen Sie von der Sprache Ihres Teams aus und fragen Sie dann, ob Sie reine WebSockets oder Socket.IO testen und wie streng Sie gepushte Nachrichten prüfen müssen. Danach bleiben meist ein oder zwei Kandidaten.

Schreiben Sie in beiden denselben kurzen Test mit Verbinden, Senden und Empfangen, und vergleichen Sie Verbindungsaufbauzeit und Nachrichtenlatenz bei geringer Last. Unsere Anleitung Lasttest durchführen führt durch die Schritte, und der Überblick Open-Source-Lasttest-Tools vergleicht diese Projekte über WebSockets hinaus.

FAQ

Mit welchem WebSocket-Lasttest-Tool sollte ich anfangen? Wenn Ihr Team JavaScript schreibt, beginnen Sie mit k6, das WebSocket-Unterstützung eingebaut hat. Für Socket.IO-Apps braucht die Engine von Artillery am wenigsten Code, und JVM-Teams fühlen sich in Gatling zu Hause.

Kann JMeter WebSockets ohne Plugin testen? Die Komponentenreferenz nennt keinen WebSocket-Sampler, der praktische Weg ist also das Plugin WebSocket Samplers, installiert über den Plugins Manager oder als JAR in lib/ext.

Sollte ich k6/ws oder k6/websockets verwenden? Nehmen Sie für neue Tests k6/websockets, wie die Dokumentation von k6 empfiehlt. Das ältere Modul k6/ws ist für bestehende Skripte weiter dokumentiert.

Weiterlesen

Lasttest durchführen: eine Schritt-für-Schritt-Anleitung

Thu, 08 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, einem in diesem Artikel erwähnten Lasttest-Dienst.

Für einen Lasttest legen Sie fest, wie ein gutes Ergebnis aussieht, skripten eine realistische Nutzerreise, prüfen das Skript mit einem einzelnen Nutzer und steigern dann die Last in Stufen, während Sie Antwortzeiten und Fehler beobachten. Vergleichen Sie das Gemessene mit dem Ziel vom Anfang und ändern Sie vor dem nächsten Lauf immer nur eine Sache.

Schritt	Was Sie tun	Fertig, wenn
1. Ziel festlegen	Die zu testende Last und die Zahlen für ein Bestanden wählen	Sie die Kriterien in einem Satz aufschreiben können
2. Nutzerreise skripten	Einen echten Nutzerpfad in ein Skript übertragen	Das Skript ohne Fehler läuft
3. Smoke-Test	Mit einem virtuellen Benutzer ausführen	Jede Prüfung besteht
4. Last steigern	Last in Stufen erhöhen und am Ziel halten	Das Ziel oder eine Abbruchbedingung erreicht ist
5. Ergebnisse lesen	Perzentile und Fehler mit dem Ziel vergleichen	Sie wissen, ob er bestanden hat und was sich ändern muss

Was sollten Sie vor einem Lasttest festlegen?

Legen Sie fest, für welche Last Sie testen und welches Ergebnis als bestanden gilt. Ohne beides liefert ein Lasttest Zahlen, aber keine Antwort.

Gehen Sie von echtem Traffic aus, wenn Sie welchen haben. Analytics oder Zugriffslogs zeigen die stärkste Stunde, wie viele Anfragen pro Sekunde ankommen und welche Seiten oder Endpunkte den Großteil davon abbekommen. Setzen Sie das Ziel über diese Spitze, denn es geht darum zu wissen, dass Sie Reserve haben. Schreiben Sie dann die Kriterien als Zahlen auf, zum Beispiel: Das 95. Perzentil der Antwortzeit bleibt unter 500 ms und weniger als 1 % der Anfragen schlagen fehl, bei 200 virtuellen Benutzern.

Zwei praktische Entscheidungen gehören ebenfalls hierher. Wählen Sie eine Umgebung, die der Produktion in Größe und Konfiguration ähnelt, denn ein Staging-Server mit einem Viertel der Kapazität sagt wenig über die Produktion. Und stellen Sie sicher, dass Sie sie testen dürfen: Ein Lasttest gegen ein System, das Ihnen nicht gehört oder das Sie mit anderen Teams teilen, sieht ohne Vorwarnung genau wie ein Angriff aus.

Wie skriptet man eine realistische Nutzerreise?

Skripten Sie den Pfad, der für das Geschäft am wichtigsten ist, Schritt für Schritt und mit Pausen dort, wo ein echter Mensch lesen oder tippen würde. Ein Skript, das eine einzige URL so schnell wie möglich aufruft, misst zwar etwas, aber selten das, worauf es ankommt.

Bei einem Shop könnte das so aussehen: Startseite öffnen, suchen, ein Produkt öffnen, in den Warenkorb legen. Bei einer API: anmelden, Einträge auflisten, einen Eintrag abrufen. Bauen Sie zwischen den Schritten eine kurze Pause ein (Think Time), verwenden Sie wechselnde Testdaten, damit sich Caches wie im echten Betrieb verhalten, und prüfen Sie jede Antwort, damit eine Fehlerseite nicht als schnelle Antwort durchgeht.

Hier ist das Skript, das wir für den Beispiellauf in dieser Anleitung verwendet haben, geschrieben für k6. Es fährt auf 10 virtuelle Benutzer hoch, hält die Last und fährt wieder herunter, mit zwei eingebauten Kriterien:

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Eine echte Nutzerreise hat mehrere Anfragen und echte URLs. Diese bleibt bewusst winzig, damit die Schritte leicht nachzuvollziehen sind.

Warum zuerst ein Smoke-Test mit einem Nutzer?

Ein Smoke-Test mit einem virtuellen Benutzer beweist, dass das Skript funktioniert, bevor Sie irgendetwas unter echte Last setzen. Er ist der billigste Weg, eine falsche URL, ein fehlendes Login-Token oder eine Prüfung zu finden, die immer fehlschlägt.

In k6 können Sie die Last über die Kommandozeile überschreiben, sodass dasselbe Skript einmal mit einem einzigen Benutzer läuft:

k6 run --vus 1 --iterations 1 script.js

Bei unserem Lauf bestand die eine Prüfung, das Skript war also bereit für Last. Wenn hier eine Prüfung fehlschlägt, reparieren Sie zuerst das Skript: Fehler bei einem Nutzer werden bei hundert zu Rauschen.

Wie sollte man die Last steigern?

Erhöhen Sie die Last in Stufen und halten Sie jede Stufe lange genug, damit sie sich einpendelt, statt direkt auf das Ziel zu springen. Eine stufenweise Rampe zeigt Ihnen, ab welcher Last es schlechter wird.

Eine übliche Form: auf eine erste Stufe hochfahren, einige Minuten halten, auf die nächste Stufe hochfahren, wieder halten und so weiter bis zum Ziel, dann herunterfahren. Wenn Sie jede Haltephase einzeln betrachten, sehen Sie, ob die Antwortzeiten gleichmäßig mit der Last steigen oder erst flach bleiben und dann springen. Dieser Sprung, der Punkt, an dem jeder zusätzliche Nutzer jede Anfrage langsamer macht, ist das Nützlichste, was ein Lasttest finden kann. Unser Beispiel fährt nur auf 10 Benutzer hoch und hält 20 Sekunden, genug, um die Stufen zu zeigen, aber viel zu kurz für einen echten Test.

Was sollten Sie während des Tests beobachten?

Beobachten Sie die Perzentile der Antwortzeit, die Fehlerrate und den Durchsatz auf Seiten des Lastgenerators sowie CPU, Speicher und Datenbanklast auf dem getesteten System. Die ersten drei sagen Ihnen, wie es sich für Nutzer anfühlen würde, die letzten drei, warum.

Vereinbaren Sie vor dem Start Abbruchbedingungen, zum Beispiel: abbrechen, wenn die Fehlerrate 5 % übersteigt oder die Antwortzeiten mehrere Sekunden erreichen. Ein System weiter zu belasten, das bereits umgefallen ist, bringt keine Erkenntnis, und in einer geteilten Umgebung stört es die Arbeit anderer.

Beobachten Sie auch den Lastgenerator. Wenn er bei voller CPU-Auslastung läuft, können die langsamen Antworten von Ihrem eigenen Laptop kommen statt vom Server.

Wie liest man die Ergebnisse eines Lasttests?

Lesen Sie die Perzentile und die Fehlerrate gegen die Kriterien, die Sie zu Beginn aufgeschrieben haben. Die durchschnittliche Antwortzeit ist die am wenigsten nützliche Zahl im Bericht.

Das hat unser Beispiellauf gemeldet (35 Sekunden, bis zu 10 virtuelle Benutzer, eine kleine statische Seite auf einem Laptop, ausgeführt am 8. Oktober 2026):

Metrik	Wert
Anfragen	282 (8 pro Sekunde)
Fehlgeschlagene Anfragen	0 %
Durchschnittliche Antwortzeit	0,69 ms
90. Perzentil	0,66 ms
95. Perzentil	0,71 ms
99. Perzentil	2,68 ms
Langsamste Anfrage	15,98 ms
Thresholds	Beide bestanden

Die Zahlen sind winzig, weil das Ziel eine statische Datei auf demselben Rechner war, sie taugen also nicht als Benchmark. Die Lehre steckt in der Form: Der Durchschnitt lag über dem 90. Perzentil, weil eine Handvoll langsamer Anfragen ihn nach oben gezogen hat. Perzentile beschreiben, was die meisten Anfragen erlebt haben, und das 99. Perzentil und die langsamste Anfrage zeigen den Ausläufer, den einige wenige Nutzer treffen. Bewerten Sie den Lauf am Perzentil aus Ihren Kriterien und nutzen Sie den Ausläufer, um zu entscheiden, ob etwas genauer angeschaut werden muss.

Wenn ein Lauf sein Ziel verfehlt, ändern Sie eine Sache (eine Abfrage, eine Cache-Einstellung, eine Instanzgröße) und führen Sie denselben Test erneut aus, damit Sie wissen, was den Unterschied gemacht hat.

Wann sollte der Test aus der Cloud laufen?

Verlegen Sie den Lastgenerator in die Cloud, wenn ein Rechner die nötige Last nicht erzeugen kann oder wenn es darauf ankommt, wo Ihre Nutzer sind. Ein Laptop im Büro-WLAN misst Ihre Büroverbindung genauso wie Ihren Server.

Dasselbe k6-Skript kann auf Infrastruktur laufen, die Sie selbst betreiben, auf dem gehosteten Dienst von Grafana oder bei LoadFocus, das k6-Skripte aus 25 Cloud-Regionen ausführt. Die Berichte dort schlüsseln Ergebnisse nach Standort auf und zeigen die Antwortzeit im Verhältnis zur Zahl der virtuellen Benutzer, und genau dort wird der oben beschriebene Sprung sichtbar (Ergebnisse in LoadFocus lesen).

FAQ

Wie lange sollte ein Lasttest laufen? Lange genug, um die Ziellast nach dem Hochfahren mehrere Minuten zu halten, damit kurze Spitzen nicht über das Ergebnis entscheiden. Mindestens 10 Minuten Haltezeit sind ein vernünftiger Start, deutlich länger, wenn Sie nach Speicherlecks oder schleichender Verschlechterung suchen.

Wie viele virtuelle Benutzer brauche ich? Leiten Sie es aus echtem Traffic ab. Nehmen Sie die Anfragen pro Sekunde der stärksten Stunde, schätzen Sie, wie viele Anfragen eine Nutzerreise macht und wie lange sie dauert, und bemessen Sie die virtuellen Benutzer so, dass der Test diese Rate plus etwas Reserve erzeugt.

Ist es sicher, die Produktion zu testen? Das kann es sein, mit Vorsicht: zu einer ruhigen Zeit testen, die Verantwortlichen informieren, Abbruchbedingungen festlegen und deutlich unter der erwarteten Spitze beginnen. Viele Teams bevorzugen eine Staging-Umgebung in Produktionsgröße, damit ein fehlgeschlagener Test keine Kunden treffen kann.

Weiterlesen

k6 vs Artillery: welches Lasttest-Tool passt zu Ihrem Team?

Thu, 08 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

k6 und Artillery sind beide quelloffene Lasttest-Tools, bei denen Tests als Code entstehen, und beide testen eine HTTP-API zuverlässig unter Last. Nehmen Sie k6, wenn Sie ein einzelnes Binary, Testlogik in JavaScript und eingebaute Pass/Fail-Schwellenwerte wollen. Nehmen Sie Artillery, wenn Ihr Team ohnehin mit Node.js arbeitet, kurze YAML-Szenarien bevorzugt oder Playwright-Browsertests und verteilte Läufe auf AWS oder Azure direkt von der Kommandozeile braucht.

Die folgenden Fakten stammen aus der Dokumentation und den Repositories der beiden Projekte, geprüft am 8. Oktober 2026.

	k6	Artillery
Lizenz	AGPL-3.0 (Repository)	MPL-2.0, einige Azure-Module unter BSL (Repository)
Laufzeit	Ein Go-Binary mit eingebetteter JavaScript-Engine	Node.js, aktuelle LTS-Version
Testskripte	JavaScript	YAML, TypeScript oder JavaScript
Kernprotokolle	HTTP, WebSockets, gRPC	HTTP, WebSocket, Socket.IO (gRPC und Kinesis als Zusatz-Engines)
Browsertests	Eingebautes Browser-Modul	Playwright
Pass/Fail-Prüfungen	Thresholds	`ensure`-Plugin
Skalierung	k6-operator auf Kubernetes oder Grafana Cloud k6	`run-lambda` oder `run-fargate` auf AWS, `run-aci` auf Azure

Was ist der Unterschied zwischen k6 und Artillery?

Sie unterscheiden sich vor allem in der Laufzeitumgebung und darin, wie Sie Last beschreiben. k6 ist ein kompiliertes Go-Tool, das JavaScript-Testcode ausführt, Artillery ist ein Node.js-Tool, das YAML- oder JavaScript-Szenarien liest.

Das merken Sie schon am ersten Tag. Für k6 installieren Sie ein Paket oder ein eigenständiges Binary, ohne eine Laufzeitumgebung pflegen zu müssen. Artillery braucht Node.js und wird über npm installiert. In einem JavaScript-Projekt fühlt sich das natürlich an, überall sonst ist es eine weitere Laufzeitumgebung, die aktuell bleiben muss.

Bei den Protokollen deckt die Schnittmenge den Großteil der Webarbeit ab: Beide sprechen von Haus aus HTTP und WebSockets. k6 bringt außerdem gRPC mit, Artillery Socket.IO. gRPC und Kinesis bekommt Artillery über Zusatz-Engines, die Sie separat installieren (geprüft am 9. Oktober 2026), und k6 reicht über sein Ökosystem an Erweiterungen weiter.

Wie schreibt man in beiden Tools einen Test?

In k6 schreiben Sie ein JavaScript-Modul mit den Optionen oben und einer Default-Funktion, die jeder virtuelle Benutzer ausführt. In Artillery schreiben Sie meist eine YAML-Datei mit einem config-Block für die Last und einem scenarios-Block für das, was jeder virtuelle Benutzer tut.

Ein k6-Test, der auf 20 virtuelle Benutzer hochfährt und fehlschlägt, wenn das 95. Perzentil der Antwortzeit über 500 ms steigt:

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 20 },
    { duration: "1m", target: 20 },
    { duration: "15s", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<500"] },
};

export default function () {
  const res = http.get("https://staging.example.com/api/users");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Dieselbe Idee im YAML-Format von Artillery, mit zehn neuen virtuellen Benutzern pro Sekunde über eine Minute:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500
scenarios:
  - flow:
      - get:
          url: "/api/users"

Die beiden Beispiele modellieren Last auf unterschiedliche Weise. Das k6-Skript legt eine Anzahl gleichzeitiger virtueller Benutzer fest, die Artillery-Datei legt fest, wie viele neue virtuelle Benutzer pro Sekunde ankommen. k6 kann Ankunftsraten auch über seine Scenario-Executors steuern, und Artillery kann die Parallelität mit maxVusers begrenzen. Wählen Sie also das Modell, das dazu passt, wie echter Traffic Ihr System erreicht, und nicht das, das ein Tool zuerst zeigt.

Wie entscheiden k6 und Artillery, ob ein Test bestanden ist?

Beide übersetzen ein Performance-Ziel in einen Exit-Code, und genau den braucht eine CI-Pipeline. Ein verfehltes Ziel beendet den Lauf in beiden Tools mit einem Exit-Code ungleich null.

In k6 heißen die Ziele Thresholds und stehen wie im Beispiel oben in den Optionen des Skripts. In Artillery stehen sie im ensure-Plugin, das einfache Schwellenwerte und Bedingungen über mehrere Metriken hinweg unterstützt.

Der praktische Unterschied liegt darin, wo die Ziele stehen. k6-Thresholds liegen in derselben Datei wie die Testlogik. Die Prüfungen von Artillery liegen im config-Block, wo sie auch jemand anpassen kann, der die Szenarien nie anfasst.

Wie fährt man einen Test, der größer ist, als ein Rechner erzeugen kann?

Beide Tools können einen Test auf viele Rechner verteilen, aber auf ganz unterschiedlichen Wegen. k6 setzt auf Kubernetes oder den gehosteten Dienst von Grafana, Artillery auf Ihr eigenes AWS- oder Azure-Konto.

Für k6 verteilt der k6-operator einen Test auf Pods in einem Kubernetes-Cluster, und Grafana Cloud k6 führt dieselben Skripte als gehosteter Dienst aus. Für Artillery starten die Befehle run-lambda und run-fargate Worker in Ihrem AWS-Konto, nach einer einmaligen IAM-Einrichtung über einen CloudFormation-Stack. Auf Azure macht run-aci dasselbe mit Azure Container Instances, braucht über eine Evaluierung hinaus aber ein kostenpflichtiges Artillery-Abo (geprüft am 9. Oktober 2026). Wenn Sie bereits Kubernetes betreiben, wirkt der Weg über den Operator vertraut. Wenn Sie lieber gar nichts betreiben möchten, hat der serverlose Weg von Artillery weniger bewegliche Teile, solange der Test in AWS oder Azure laufen darf.

Für k6-Skripte gibt es einen dritten Weg. LoadFocus führt k6-Skripte auf seiner eigenen Cloud-Infrastruktur aus 25 Regionen aus, sodass aus dem Skript auf Ihrem Laptop ein verteilter Test wird, ganz ohne Cluster oder AWS-Konto. LoadFocus führt keine Artillery-Skripte aus, für Artillery bleiben also seine eigenen AWS- und Azure-Befehle der Weg zur Skalierung.

Wohin gehen die Ergebnisse?

Beide Tools geben am Ende eines Laufs eine Zusammenfassung aus und können Metriken für Dashboards und Alarme an andere Systeme senden.

k6 bietet laut seinem Repository Zusammenfassungen oder detaillierte Metriken, die an den Dienst Ihrer Wahl exportiert werden. Artillery nennt in seinem Repository mehr als 20 Integrationen für Monitoring, Observability und CI/CD. Beide Tools können also die Dashboards füttern, die Sie schon haben. Prüfen Sie vorher, ob genau die Ausgabe, die Sie brauchen, auf der Liste steht, denn beide Listen ändern sich von Version zu Version.

Welches Tool sollten Sie wählen?

Wählen Sie k6, wenn Sie ein einzelnes Binary in der CI, JavaScript-Testlogik mit echtem Kontrollfluss und Thresholds in derselben Datei wie den Test wollen. Es passt auch zu Teams, die bereits Grafana nutzen, weil das Open-Source-Tool und der gehostete Dienst dieselbe Skript-API teilen.

Wählen Sie stattdessen Artillery, wenn Ihr Team täglich Node.js schreibt, wenn eine kurze YAML-Datei für den Rest des Teams leichter zu prüfen ist als ein Skript oder wenn Sie Playwright-Browsertests und Socket.IO im selben Tool brauchen. Seine serverlose Skalierung ist auch der kürzere Weg, wenn Ihre Infrastruktur ohnehin in AWS liegt und Kubernetes keine Rolle spielt.

Wenn Sie noch unentschlossen sind, schreiben Sie denselben Smoke-Test in beiden Tools. Zwanzig Zeilen reichen, um zu sehen, welches Ihr Team im Code-Review leichter liest.

FAQ

Ist k6 kostenlos? Ja. k6 ist Open Source unter der Lizenz AGPL-3.0 und läuft kostenlos auf Ihren eigenen Rechnern. Grafana Cloud k6 ist ein separater gehosteter Dienst mit eigener Preisgestaltung.

Ist Artillery kostenlos? Größtenteils. Der Großteil von Artillery steht unter der Lizenz MPL-2.0, einige Azure-spezifische Module nutzen jedoch eine Source-Available-Lizenz, die für den produktiven Einsatz auf Azure eine kommerzielle Lizenz verlangt, so das Repository des Projekts (geprüft am 8. Oktober 2026).

Kann LoadFocus Artillery-Tests ausführen? Nein. LoadFocus führt k6- und JMeter-Skripte aus. Um einen Artillery-Test über einen Rechner hinaus zu skalieren, nutzen Sie die Befehle von Artillery für AWS Lambda, Fargate oder Azure Container Instances in Ihrem eigenen Cloud-Konto.

Welches Tool braucht weniger Ressourcen auf dem Lastgenerator? Das haben wir nicht selbst gemessen, deshalb nennen wir keinen Sieger. Das k6-Projekt sagt, dass selbst schwächere Rechner viel Traffic simulieren können, und fair vergleichen lässt sich das nur, wenn Sie dasselbe Szenario mit beiden Tools auf Ihrer eigenen Hardware laufen lassen.

Weiterlesen

Open-Source-Lasttest-Tools: sechs Optionen im Überblick

Thu, 08 Oct 2026 00:00:00 GMT

Offenlegung: loadtest.app wird von LoadFocus herausgegeben, das einen in diesem Artikel behandelten Lasttest-Dienst verkauft.

Sechs verbreitete Open-Source-Lasttest-Tools sind derzeit Apache JMeter, k6, Gatling, Locust, Artillery und Vegeta. Wählen Sie nach der Sprache, in der Ihr Team Tests schreibt, und danach, wie Sie skalieren müssen: JMeter für die größte Protokollabdeckung, k6 oder Artillery für JavaScript, Gatling für die JVM, Locust für Python und Vegeta für schnelle HTTP-Prüfungen mit fester Rate.

Für diesen Artikel haben wir die Tools nicht gegeneinander gebenchmarkt. Die Fakten stammen aus den Repositories und der Dokumentation der Projekte, geprüft am 8. Oktober 2026, und die Hinweise unter „Gut für“ sind unsere Einschätzung.

Tool	Lizenz	Tests geschrieben in	Läuft auf	Last auf mehrere Rechner verteilen
Apache JMeter	Apache 2.0	In einer Desktop-GUI gebaute Testpläne	Java	Eingebauter Remote-Modus (Client-Server)
k6	AGPL-3.0	JavaScript	Ein Go-Binary	k6-operator auf Kubernetes
Gatling	Apache 2.0 (einige Komponenten unter einer Enterprise-Lizenz)	Java, Kotlin, Scala, JavaScript, TypeScript	JVM	Kommerzielle Enterprise-Edition
Locust	MIT	Python	Python	Eingebaut
Artillery	MPL-2.0 (einige Azure-Module unter BSL)	YAML, JavaScript, TypeScript	Node.js	AWS Lambda, Fargate oder Azure ACI über die CLI
Vegeta	MIT	Kommandozeile oder Go-Code	Ein Go-Binary	Mehrere Instanzen starten

Lohnt sich Apache JMeter noch?

Ja, besonders wenn Sie Protokolle jenseits von HTTP brauchen. JMeter deckt von den sechs Tools das breiteste Spektrum ab und hat den größten Bestand an vorhandenen Testplänen und Wissen.

JMeter ist eine Java-Anwendung unter der Lizenz Apache 2.0. Die Protokollliste umfasst HTTP und HTTPS, SOAP- und REST-Webservices, FTP, Datenbanken über JDBC, LDAP, JMS-Messaging, E-Mail und rohes TCP. Testpläne bauen Sie in einer Desktop-GUI, für echte Tests führen Sie sie ohne GUI über die Kommandozeile aus, und der Client-Server-Remote-Modus verteilt einen Test auf mehrere Rechner.

Gut für Systeme mit gemischten Protokollen, Teams mit vorhandenen JMeter-Plänen und Tester, die Tests lieber visuell aufbauen. Wählen Sie etwas anderes, wenn Ihr Team Tests als reinen Code will, der wie die Anwendung geprüft wird, denn in der GUI gebaute XML-Pläne sind in einem Pull Request schwer zu lesen.

Wann ist k6 die richtige Wahl?

Wenn Ihr Team JavaScript schreibt und Tests als Code mit eingebauten Pass/Fail-Schwellenwerten will. k6 kommt als einzelnes Go-Binary, was die Einrichtung in der CI einfach hält.

k6 steht unter der Lizenz AGPL-3.0 und spricht HTTP, WebSockets und gRPC, dazu kommt ein Browser-Modul für Frontend-Prüfungen. Thresholds machen aus einem Ziel wie einer Grenze für das 95. Perzentil einen Exit-Code ungleich null für die CI. Zum Skalieren führt der k6-operator verteilte Tests auf Kubernetes aus, und Grafana verkauft einen gehosteten Dienst.

Gut für Entwickler, die API-Tests neben ihrem Code pflegen, und für CI-Pipelines. Wählen Sie etwas anderes, wenn Ihr Team kein JavaScript will oder die AGPL-Lizenz nicht dazu passt, wie Sie das Tool einbetten oder ausliefern. Den direkten Vergleich finden Sie in k6 vs Artillery.

Für wen ist Gatling gedacht?

Für Teams auf der JVM, die Tests als Code und von Haus aus einen detaillierten HTML-Bericht wollen. Gatling bietet außerdem ein JavaScript- und TypeScript-SDK auf derselben Engine.

Gatling lässt virtuelle Benutzer auf einer nicht blockierenden Engine auf Basis von Netty laufen, sodass ein einzelner Rechner viel Last erzeugen kann. Simulationen entstehen in Java, Kotlin, Scala, JavaScript oder TypeScript und laufen über Plugins für Maven, Gradle, sbt oder npm. Die Community-Edition steht unter Apache 2.0 und deckt HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events und JMS ab, während die Komponenten für gRPC, MQTT und GraphQL unter der Enterprise-Komponentenlizenz von Gatling stehen.

Gut für Java- und Scala-Teams und für alle, die ausführliche Berichte ohne zusätzliche Werkzeuge wollen. Wählen Sie etwas anderes, wenn Sie Last allein mit der Open-Source-Edition auf mehrere Rechner verteilen müssen: Last aus verwalteter oder privater Infrastruktur zu erzeugen, ist die Aufgabe des kommerziellen Gatling Enterprise.

Ist Locust eine gute Wahl für Python-Teams?

Ja. Locust-Tests sind reines Python, Schleifen, Bedingungen und jede Python-Bibliothek funktionieren also wie in normalem Code.

Locust steht unter der MIT-Lizenz und arbeitet ereignisbasiert mit gevent, wodurch ein einzelner Prozess viele Benutzer bedienen kann. Tests laufen über die Kommandozeile oder eine Web-Oberfläche, die Durchsatz, Antwortzeiten und Fehler live zeigt, und Locust verteilt einen Test von sich aus auf mehrere Rechner. HTTP ist eingebaut, weitere Protokolle kommen durch eigenen Python-Code hinzu.

Gut für Python-Teams, Szenarien mit komplexer Logik und alle, die einen Test gern im Browser verfolgen. Wählen Sie etwas anderes, wenn Sie deklarative Tests im Konfigurationsstil wollen oder ein fertiges Plugin für ein ungewöhnliches Protokoll wichtiger ist, als selbst eines zu schreiben.

Wann ist Artillery sinnvoll?

Wenn Ihr Team mit Node.js arbeitet, kurze YAML-Szenarien mag oder Playwright-Browsertests im selben Tool wie die API-Tests will.

Artillery steht größtenteils unter MPL-2.0, einige Azure-Module unter einer Source-Available-Lizenz. Es bringt HTTP, WebSocket und Socket.IO mit, gRPC und Kinesis kommen über Zusatz-Engines hinzu, und die Befehle run-lambda und run-fargate verteilen einen Test auf Worker in Ihrem eigenen AWS-Konto. Der Befehl run-aci macht dasselbe auf Azure Container Instances, über eine Evaluierung hinaus mit einem kostenpflichtigen Artillery-Abo (geprüft am 9. Oktober 2026).

Gut für Node.js-Teams, gemischte API- und Browsertests und Firmen, die bereits AWS nutzen. Wählen Sie etwas anderes, wenn Sie Node.js nicht auf Ihren Lastgeneratoren haben wollen oder große Tests außerhalb von AWS und Azure laufen müssen.

Wofür eignet sich Vegeta?

Für schnelle HTTP-Prüfungen mit konstanter Rate von der Kommandozeile. Es erledigt eine Aufgabe, Anfragen mit fester Rate zu senden, und hält diese Aufgabe einfach.

Vegeta ist ein Go-Tool unter der MIT-Lizenz, das als Kommandozeilenprogramm oder als Go-Bibliothek funktioniert, mit einer CLI, die sich mit anderen Unix-Werkzeugen kombinieren lässt. Weil es die Anfragerate konstant hält, statt Benutzer zu modellieren, beantwortet es Fragen wie „Was passiert bei 500 Anfragen pro Sekunde?“ besser, als es Nutzerreisen abbildet.

Gut für schnelle Prüfungen eines Endpunkts, Kapazitätstests mit fester Rate und Shell-Skripte. Wählen Sie etwas anderes, wenn Sie mehrstufige Nutzerreisen, Think Time oder ausführliche Berichte brauchen.

Wo passt ein gehosteter Runner wie LoadFocus hinein?

Keines dieser Tools braucht einen gehosteten Dienst, aber große oder geografisch verteilte Last von eigenen Rechnern zu erzeugen, macht Arbeit. Ein gehosteter Runner übernimmt die Lasterzeugung und lässt Ihre Skripte, wie sie sind.

LoadFocus, der Herausgeber dieser Website, ist ein solcher Dienst. Er führt vorhandene JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen aus. Tests für Gatling, Locust, Artillery oder Vegeta führt er nicht aus, für diese Tools gelten also die oben beschriebenen Wege zur Skalierung. Grafana Cloud k6 und Gatling Enterprise sind die gehosteten Wege der Hersteller für k6 und Gatling.

Wie wählt man zwischen ihnen?

Gehen Sie von der Sprache aus, die Ihr Team bereits schreibt, und von den Protokollen, die Sie testen müssen, und prüfen Sie dann, wie jedes Tool skaliert. Damit schrumpfen sechs Optionen meist auf eine oder zwei.

Schreiben Sie dann denselben kurzen Test in Ihren zwei Favoriten. Beide nebeneinander zu lesen, entscheidet die meisten Diskussionen schneller als jede Funktionstabelle, und unsere Anleitung Lasttest durchführen führt Schritt für Schritt durch diesen ersten Test.

FAQ

Mit welchem Open-Source-Lasttest-Tool fängt man am leichtesten an? Für einen einzelnen HTTP-Endpunkt liefern Vegeta oder k6 innerhalb von Minuten ein Ergebnis, weil beide aus einem einzigen Binary bestehen. Für mehrstufige Nutzerreisen nehmen Sie das Tool, dessen Testsprache Ihr Team bereits schreibt.

Können Open-Source-Lasttest-Tools verteilte Tests ausführen? Ja, auf unterschiedlichen Wegen: JMeter hat einen eingebauten Remote-Modus, Locust verteilt von sich aus auf mehrere Rechner, k6 nutzt den k6-operator auf Kubernetes und Artillery nutzt AWS Lambda, Fargate oder Azure Container Instances. Bei Gatling gehört die Lasterzeugung aus verwalteter oder privater Infrastruktur zur kommerziellen Enterprise-Edition.

Ist JMeter besser als k6? Keines ist allgemein besser. JMeter deckt mehr Protokolle ab und passt zu GUI-basiertem Testdesign, k6 passt zu Entwicklern, die Tests als JavaScript-Code in der CI wollen.