Welche Jitter-Art sollte ich wählen?

In den meisten Fällen genügt voller oder gleicher Jitter. Greifen viele Clients auf dieselbe Ressource zu, verteilt voller Jitter die Last am besten; wählen Sie gleichen Jitter, wenn Sie eine garantierte Mindestwartezeit wollen. Wiederholen ohne Jitter ist nur bei einem einzelnen Client unter geringer Last vertretbar.

Kann ich meine Berechnung ignorieren, wenn ein Retry-After-Header da ist?

Nein. Hat der Server eine Zeit genannt, ist ein früherer Versuch sinnlos; die Wartezeit muss mindestens Retry-After betragen. Ist Ihr berechnetes Backoff länger, nutzen Sie dieses. Der Header kann eine Sekundenzahl oder ein HTTP-Datum sein; werten Sie beides aus.

Welche Fehler sollten wiederholt werden?

Vorübergehende: Netzabbrüche und Timeouts, 429, 502, 503, 504 und oft 500. Clientfehler wie 400, 401, 403, 404 und 422 liefern beim Wiederholen dasselbe Ergebnis; wiederholen Sie sie nicht. Begrenzen Sie immer Anzahl und Gesamtdauer der Wiederholungen.

Ist es sicher, eine POST-Anfrage zu wiederholen?

Nicht von selbst. Nach einem Timeout kann der Server den Vorgang abgeschlossen haben; erneutes Senden erzeugt eine doppelte Bestellung oder Zahlung. Senden Sie einen Idempotency-Key-Header und prüfen Sie, dass der Server denselben Schlüssel mit demselben Ergebnis beantwortet.

Der Zufall stammt aus dem Seed, nicht aus einer echten Zufallsquelle; derselbe Seed liefert dieselben Verzögerungen. So können Sie ein Szenario mit Kollegen teilen und eine Testerwartung festlegen. Legen Sie den Seed in einem echten Client nicht fest.

API-Retry- und Backoff-Simulator

Sehen Sie vorab, wie lange ein Client wartet, wenn ein API-Aufruf 429 oder 503 liefert. Geben Sie Ihre Verzögerungswerte ein; mit deterministischem Jitter per Seed erhalten Sie den Zeitpunkt jedes Versuchs, die Gesamtwartezeit und die Verteilung über viele Läufe. Die Berechnung verlässt Ihr Gerät nicht.

Kostenloses Werkzeug · Integration

Voreinstellung

StartverzögerungmsBasiswartezeit vor dem ersten Wiederholungsversuch.Faktor×Die Verzögerung wird bei jedem Versuch mit dieser Zahl multipliziert; 2 ist üblich, 1 bedeutet konstanten Abstand.ObergrenzemsKeine einzelne Wartezeit überschreitet diesen Wert.Anzahl WiederholungenStückOhne die erste Anfrage, höchstens 20.

Retry-After-Hinweis (optional)msHat der Server eine Wartezeit genannt, ist jede Verzögerung mindestens so lang. Leer lassen oder Millisekunden eingeben.

Jitter-Art

KeinerAlle Clients wiederholen gleichzeitig; die Last kommt in Wellen zurück.VollWartezeit zufällig zwischen 0 und der Obergrenze des Schritts; verteilt die Last am besten, manche Versuche kommen sehr früh.GleichWartezeit ist die Hälfte der Schrittobergrenze plus eine zufällige Hälfte; hält eine Untergrenze, verengt die Streuung etwas.DekorreliertWartezeit zufällig zwischen Startverzögerung und dem Dreifachen der vorigen Wartezeit; unabhängig vom Faktor.

SeedDerselbe Seed erzeugt dieselben Verzögerungen; so lässt sich ein Ergebnis teilen und reproduzieren.

Die Berechnung läuft in Ihrem Browser; kein Wert wird an einen Server gesendet.

Gesamtwartezeit (dieser Seed): 25,47 s
Gesamtwartezeit ohne Jitter: 51 s
Mittlere Gesamtwartezeit: 25,06 s
95.-Perzentil der Gesamtwartezeit: 39,4 s
Längste Gesamtwartezeit: 45,37 s

Die letzten drei Werte stammen aus 500 aufeinanderfolgenden Seeds ab diesem Seed.

Zeitachse

Versuchstabelle

Versuchstabelle
Versuch	Obergrenze	Wartezeit	Kumuliert
1	200 ms	120 ms	120 ms
2	400 ms	179 ms	299 ms
3	800 ms	682 ms	981 ms
4	1,6 s	1,07 s	2,05 s
5	3,2 s	559 ms	2,61 s
6	6,4 s	3,37 s	5,98 s
7	12,8 s	3,5 s	9,48 s
8	25,6 s	15,99 s	25,47 s

Pseudocode

for attempt in 0..7:
  exp = min(30000, 200 * 2 ** attempt)
  delay = random(0, exp)
  sleep(delay)

In der Praxis

Bei 429 (Too Many Requests) und 503 (Service Unavailable) kann der Server einen Retry-After-Header senden (Sekunden oder HTTP-Datum). Ist er vorhanden, gehen Sie nicht unter Ihre eigene Berechnung: Wartezeit = max(berechnet, Retry-After). Ohne Header liegt das Backoff in Ihrer Verantwortung.
Wiederholen ist nur bei Anfragen sicher, deren Wiederholung unschädlich ist. GET, PUT und DELETE gelten per Definition als idempotent, POST nicht. Wiederholen Sie ein POST wie eine Zahlung oder Bestellung, droht eine Doppelbuchung: Senden Sie einen Idempotency-Key-Header und stellen Sie sicher, dass der Server den Schlüssel tatsächlich unterstützt.
Ohne Jitter wiederholen Tausende Clients gleichzeitig (Thundering Herd) und werfen den sich erholenden Dienst erneut um. Voller oder gleicher Jitter verteilt diese Last über die Zeit; begrenzen Sie außerdem Anzahl und Dauer der Wiederholungen und wiederholen Sie dauerhafte Fehler (4xx außer 429) gar nicht.

Obergrenze(n) = min(Cap, Start × Faktor^(n−1)) · voll: U(0, Obergrenze) · gleich: Obergrenze/2 + U(0, Obergrenze/2) · dekorreliert: min(Cap, U(Start, vorige × 3))

Dieses Werkzeug berechnet nur Wartezeiten; es sendet keine Anfragen und misst weder Netzwerk- noch Serververhalten. Reale Verzögerungen hängen zusätzlich von Anfragedauer, Timeouts und den Einstellungen Ihrer Client-Bibliothek ab. Die Ergebnisse sind Beispiele.

Möchten Sie Retries, Warteschlangen und Fehlerbehandlung Ihrer Integrationen gemeinsam entwerfen? Wir können trennen, welche Aufrufe sicher wiederholbar sind und wo eine Warteschlange nötig ist.

Gespräch anfragen

So funktioniert es

A
Geben Sie Startverzögerung, Faktor, Obergrenze und Anzahl der Wiederholungen ein oder wählen Sie eine Voreinstellung.
B
Wählen Sie die Jitter-Art; die Zeitachse zeigt die Wartezeiten mit Jitter (gefüllte Marken) neben der Referenz ohne Jitter (blasse Marken).
C
Prüfen Sie die Gesamtwartezeit und die Verteilung über viele Läufe; kopieren Sie den Pseudocode oder das Ergebnis und teilen Sie es mit Ihrem Team. Mit demselben Seed lässt sich das Ergebnis reproduzieren.

Wie exponentielles Backoff funktioniert

Nach jedem fehlgeschlagenen Versuch wartet der Client länger als beim vorigen: Start × Faktor^(n−1). An der Obergrenze wächst die Wartezeit nicht weiter. Ein kurzer Ausfall wird mit kurzen Versuchen schnell überbrückt, und bei einem langen Ausfall wird der Dienst nicht von Wiederholungen erdrückt.

Exponentielles Backoff allein lässt Clients, die gemeinsam gescheitert sind, gemeinsam wiederholen. Jitter bricht diesen Gleichtakt: Die Wartezeiten der Clients streuen zufällig, die Last verteilt sich über die Zeit.

Vier Jitter-Arten

Voller Jitter wählt die Wartezeit zufällig zwischen 0 und der Obergrenze des Schritts; die mittlere Wartezeit ist die Hälfte davon, die Lastverteilung ist am besten. Gleicher Jitter hält die Hälfte der Obergrenze fest und randomisiert die andere Hälfte, was eine Mindestwartezeit garantiert. Dekorrelierter Jitter koppelt jede Wartezeit an die vorige und ist vom Faktor unabhängig.

Der Simulator erlaubt den Vergleich mit demselben Seed: Seed beibehalten, Art wechseln. Ein einzelner Lauf kann täuschen, deshalb werden Mittelwert, 95. Perzentil und Maximum der Gesamtwartezeit aus 500 Läufen berechnet.

Berechnung und Annahmen

Wartezeiten werden auf Millisekunden gerundet. Der Zufall wird mit dem Generator mulberry32 aus dem Seed abgeleitet; er ist nicht kryptografisch und nur für Simulationen gedacht. Ihr echter Client nutzt eine eigene Zufallsquelle, daher ist nur die Verteilung repräsentativ, nicht die einzelnen Werte.

Anfragedauer, Timeouts und Circuit Breaker werden nicht modelliert: Die Gesamtwartezeit ist nur die Summe der Wartezeiten. Die tatsächlich verstrichene Zeit enthält zusätzlich die Dauer jedes Versuchs.

Häufige Fragen

Welche Jitter-Art sollte ich wählen?: In den meisten Fällen genügt voller oder gleicher Jitter. Greifen viele Clients auf dieselbe Ressource zu, verteilt voller Jitter die Last am besten; wählen Sie gleichen Jitter, wenn Sie eine garantierte Mindestwartezeit wollen. Wiederholen ohne Jitter ist nur bei einem einzelnen Client unter geringer Last vertretbar.
Kann ich meine Berechnung ignorieren, wenn ein Retry-After-Header da ist?: Nein. Hat der Server eine Zeit genannt, ist ein früherer Versuch sinnlos; die Wartezeit muss mindestens Retry-After betragen. Ist Ihr berechnetes Backoff länger, nutzen Sie dieses. Der Header kann eine Sekundenzahl oder ein HTTP-Datum sein; werten Sie beides aus.
Welche Fehler sollten wiederholt werden?: Vorübergehende: Netzabbrüche und Timeouts, 429, 502, 503, 504 und oft 500. Clientfehler wie 400, 401, 403, 404 und 422 liefern beim Wiederholen dasselbe Ergebnis; wiederholen Sie sie nicht. Begrenzen Sie immer Anzahl und Gesamtdauer der Wiederholungen.
Ist es sicher, eine POST-Anfrage zu wiederholen?: Nicht von selbst. Nach einem Timeout kann der Server den Vorgang abgeschlossen haben; erneutes Senden erzeugt eine doppelte Bestellung oder Zahlung. Senden Sie einen Idempotency-Key-Header und prüfen Sie, dass der Server denselben Schlüssel mit demselben Ergebnis beantwortet.
Wozu dient der Seed?: Der Zufall stammt aus dem Seed, nicht aus einer echten Zufallsquelle; derselbe Seed liefert dieselben Verzögerungen. So können Sie ein Szenario mit Kollegen teilen und eine Testerwartung festlegen. Legen Sie den Seed in einem echten Client nicht fest.

Machen wir Ihre Integrationen fehlertolerant

Wir entwerfen Retries, Warteschlangen und Idempotenz gemeinsam für CRM-, ERP- und Drittanbieter-API-Anbindungen. Besprechen wir Ihren bestehenden Ablauf in einem kostenlosen Erstgespräch.

Gespräch anfragen CRM-/ERP-Integration ansehen →