Closed vs. Open Workflow Models im Performance Testing (2026)

Wer Performance-Tests einrichtet, stößt früher oder später auf zwei Begriffe: Closed Workflow Model und Open Workflow Model. Klingt akademisch, ist aber praktisch entscheidend: das eine modelliert eine geschlossene Nutzer-Population mit fester Anzahl, das andere eine offene Ankunfts-Rate, bei der neue User unabhängig vom System-Verhalten reinströmen. Wer die Modelle vermischt, misst das Falsche.

In diesem Artikel erkläre ich beide Modelle, zeige wann du welches brauchst und wie du sie konkret in JMeter, k6 und Locust umsetzt. Plus die typischen Fehler, die ich in Kunden-Lasttests gesehen habe.

Warum Workflow Models wichtig sind

Performance-Tests simulieren Last. Aber Last ist nicht gleich Last. Wenn du 1.000 User auf dein System schickst, ist nicht egal, ob das 1.000 angemeldete User sind, die Aktionen ausführen und auf Antworten warten, oder 1.000 neue Anfragen pro Sekunde, die einfach kommen, egal wie schnell das System antwortet.

Das ist der Kern: ein Workflow Model definiert, wie User-Last entsteht. Daraus folgen unterschiedliche Reaktionen des Systems unter Last. Ein E-Commerce-Shop am Black Friday verhält sich nach Open Workflow (Kunden strömen, Anzahl ist nicht limitiert). Ein internes ERP mit 200 Mitarbeitern verhält sich nach Closed Workflow (Pool aus 200 ist fest, jeder klickt nach Response).

Wenn du das nicht trennst, misst du das falsche System-Verhalten. Faustregel: User-Population fix → Closed. Ankunfts-Rate unabhängig → Open. Wenn du erst die Grundlagen brauchst, lies den Performance-Testing-Pillar.

Closed Workflow Model erklärt

Closed Workflow simuliert eine feste Anzahl virtueller User. Jeder User schickt einen Request, wartet auf die Antwort, denkt nach (Think-Time), schickt den nächsten Request. Wenn das System langsamer wird, wartet der User länger, schickt also weniger Requests pro Sekunde. Die Last passt sich automatisch dem System an.

Mathematisch: bei N virtuellen Usern und mittlerer Response-Time R plus Think-Time T ist die Last ungefähr N / (R + T) Requests pro Sekunde. Wird R größer, sinkt die effektive Last.

Typische Szenarien für Closed Workflow:

• Internes ERP mit fester Mitarbeiterzahl
• Mobile App mit definierter Tester-Gruppe
• SaaS-Tool mit Subscription-Modell (User-Pool ist bekannt)
• Capacity-Planning auf existierender Nutzer-Basis

JMeter Thread Group ist klassisches Closed Workflow: du gibst Anzahl Threads, Ramp-up und Loop-Count an. Locust mit between(1, 3) ebenfalls. Beides simuliert User, die warten und nachdenken.

Open Workflow Model erklärt

Open Workflow definiert nicht User, sondern eine Ankunfts-Rate. Pro Sekunde kommen X neue Requests, unabhängig davon, wie schnell das System antwortet. Wird das System langsamer, stauen sich Requests in der Queue. Wird es zu langsam, verliert das System Requests oder bricht zusammen.

Mathematisch: λ = Ankunfts-Rate (Requests/Sekunde), µ = Bedienrate. Wenn λ > µ wächst die Queue unbegrenzt. Das ist Queue-Theorie, nicht User-Simulation.

Typische Szenarien für Open Workflow:

• Öffentliche Website mit unbekannter Besucher-Zahl (E-Commerce-Spike)
• Event-Driven-Architektur (Kafka-Topics mit fester Throughput)
• SLA-Definition mit konstanter RPS-Last (z.B. „500 RPS für 30 Min")
• Capacity-Planning für saisonale Spitzen

JMeter Constant Throughput Timer modelliert Open Workflow: er erzwingt eine konstante Request-Rate, egal wie viele Threads aktiv sind. k6 mit scenarios.constant-arrival-rate ist nativ Open. Locust mit constant_throughput() ebenfalls.

Vergleich: Wann nimmst du welches?

Im Zweifel beides messen. Closed gibt dir die User-Perspektive (wie schnell antwortet das System unter realistischer User-Last), Open gibt dir die System-Perspektive (welchen Durchsatz hält das System aus, wo bricht es).

Tool-Mapping: JMeter, k6, Locust

Jedes große Tool unterstützt beide Modelle, mal nativer, mal über Plugins:

k6-Beispiel für Open Workflow:

export const options = {
  scenarios: {
    api_load: {
      executor: 'constant-arrival-rate',
      rate: 500,           // 500 Requests pro Sekunde
      timeUnit: '1s',
      duration: '10m',
      preAllocatedVUs: 200,
      maxVUs: 500,
    },
  },
};

JMeter-Beispiel (Constant Throughput Timer) liefert 60 Requests pro Sekunde bei korrektem throughput=3600 (Einheit pro Minute, nicht pro Sekunde). Details im Artikel JMeter Lasttest-Praxis. Locust-Variante steht im Locust Tutorial. Für die k6-Praxis siehe k6 Performance Testing.

Drei typische Stolperfallen

1. Closed Workflow für Stresstest. Wer JMeter Thread Group nutzt und sieht, dass Antwortzeiten unter Last steigen, denkt: System bricht. In Wirklichkeit drosselt sich die Last selbst (Self-Throttling). Echter Stresstest braucht Open Workflow, sonst findest du die Bruchstelle nicht.
2. Open Workflow ohne Begrenzung. Wenn du in k6 constant-arrival-rate nutzt aber maxVUs zu niedrig setzt, drosselt das Tool die Rate von selbst. Du misst dein Test-Setup, nicht dein System.
3. Mixed Models im selben Test. Wer ein JMeter-Test-Plan mit Thread Group und Constant Throughput Timer kombiniert, bekommt ein Hybrid, das schwer zu interpretieren ist. Modelle bewusst trennen, separate Test-Pläne fahren.

Fazit

Closed und Open Workflow Models sind keine akademische Spielerei, sondern eine Pflicht-Entscheidung beim Setup eines Performance-Tests. Closed für realistische User-Simulation und Capacity auf bekannter Basis. Open für Stresstest, SLA-Durchsatz-Tests und Spike-Szenarien.

Tools wechseln. Qualitätsdenken bleibt. Welches Modell du nimmst, hängt von der Frage ab, die du beantworten willst. Beides messen, wenn du beide Fragen hast.

Für die konkrete Tool-Auswahl siehe den Performance-Testing-Tools-Vergleich 2026. Für die Grundlagen lies den Performance-Testing-Pillar.

Häufige Fragen (FAQ)

Was ist der Unterschied zwischen Closed und Open Workflow Model?

Closed Workflow simuliert eine feste Anzahl User, die nacheinander Aktionen ausführen und auf Antworten warten. Open Workflow definiert eine konstante Ankunfts-Rate, bei der neue Requests unabhängig vom System-Verhalten reinkommen. Closed ist User-zentriert, Open ist Throughput-zentriert.

Welches Modell ist besser für Stresstest?

Open Workflow. Closed Workflow drosselt die Last automatisch wenn das System langsamer wird (Self-Throttling), weshalb du die echte Bruchstelle nicht findest. Open Workflow erzwingt konstante Rate und zeigt, wann die Queue überläuft.

Wie modelliere ich Open Workflow in JMeter?

Mit dem Constant Throughput Timer oder dem Throughput Shaping Timer (Plugin). Wichtig: die Einheit ist Requests pro Minute, nicht pro Sekunde. Für 60 RPS trägst du 3600 ein. Plus calcMode 2 (alle Threads dieser Group), damit die Rate stabil bleibt.

Welches Tool ist nativ Open Workflow?

k6 mit dem constant-arrival-rate Executor ist nativ Open Workflow. Du definierst Rate, Dauer und VUs, k6 hält die Rate konstant. JMeter und Locust können Open Workflow, brauchen aber explizite Timer oder Wait-Time-Funktionen.

Kann ich Closed und Open im selben Test mischen?

Technisch ja, methodisch nicht empfohlen. Du bekommst Hybrid-Lastprofile, die schwer zu interpretieren sind. Besser: zwei separate Test-Pläne, eines pro Modell, beide nightly in der Pipeline. Vergleichen liefert klarere Insights als Mischen.

Welches Modell beschreibt einen E-Commerce-Spike am Black Friday?

Open Workflow. Kunden strömen unabhängig davon rein, wie schnell der Shop antwortet. Wenn der Shop langsam wird, gehen Kunden weg oder Requests timeout-en, aber die Ankunfts-Rate sinkt nicht. Closed Workflow würde annehmen, dass Kunden auf jede Response warten, was nicht stimmt.