Think Time im Lasttest: was sie ist und wie man sie wählt

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.

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.

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

• Offenes vs geschlossenes Lastmodell: welches passt wann?
• Little’s Law im Lasttest: Tests dimensionieren und prüfen
• Lasttest durchführen: eine Schritt-für-Schritt-Anleitung
• Warteschlangentheorie: was sie ist und warum Latenz steigt

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