Offenes vs geschlossenes Lastmodell: welches passt wann?

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.

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

• Coordinated Omission: was es ist und wie man es vermeidet
• Little’s Law im Lasttest: Tests dimensionieren und prüfen
• Think Time im Lasttest: was sie ist und wie man sie wählt
• Durchsatz vs. Latenz: wie sie unter Last zusammenhängen
• Amdahlsches Gesetz: Formel, Beispiele und Grenzen
• Warteschlangentheorie: was sie ist und warum Latenz steigt

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.