Timeout
Ein Timeout begrenzt, wie lange ein Aufrufer auf eine Antwort wartet. Er beschreibt den Zustand des Aufrufers und belegt für sich allein keinen Fehlschlag der entfernten Operation.
- ZeitbudgetMaximale Wartezeit des Aufrufers.
- UngeklärtSpäte Antwort ist kein Fehlschlag.
- ZielkonfliktKurz: viel offen. Lang: Wartezeit.
Einordnung
Warum das wichtig ist
Ein Aufrufer kann nicht ewig warten, aber ein abgelaufenes Warten sagt nichts über die entfernte Operation. Ohne diese Unterscheidung meldet der Shop einen Fehler, obwohl die Zahlung gelungen ist. Teilausfall und Idempotenz vertiefen eigene Bausteine.
Dieser Baustein erklärt Zeitbudget und ungewissen Aufrufausgang. Retry behandelt zulässige Folgeversuche; Teilausfall ordnet unvollständige Abläufe ein.
Auf einen Blick · Frist begrenzt die Wartezeit
Zeitbudget der Zahlung wählen
Das Bestellmodul übergibt eine Autorisierung an das Zahlungsmodul, das den externen Anbieter aufruft. Das Shop-Zeitbudget endet nach einer Sekunde; die Anbieterantwort trifft später ein.
So liest du das Bild
- Zeitbudget Regler mit 250, 1000 und 3000 ms; 1000 ms ist das Zeitbudget der Zahlung.
- Ungeklärt Anzeige „Status ungeklärt“ zählt die Antworten, die nach dem Zeitbudget eintreffen.
- Zielkonflikt Zusammenspiel von „rechtzeitig beantwortet“, „Status ungeklärt“ und „längste Wartezeit“ beim Verstellen.
- rechtzeitig beantwortet
- 13 von 16
- Status ungeklärt
- 3
- längste Wartezeit
- 1 s
Zeitbudget der Zahlung: Die meisten Antworten kommen rechtzeitig, wenige bleiben ungeklärt, und die Wartezeit bleibt für den Kunden tragbar.
Antwortzeiten illustrativ
Nutzen & Grenzen
Hilft, wenn
- Ein vereinbartes Antwortziel gibt Anfragepfaden eine klare Obergrenze für belegte Verbindungen und Worker.
- Mehrstufige verteilte Abläufe benötigen ein weitergereichtes Gesamtbudget für alle Teiloperationen.
Grenzen
- Zu kurze Grenzen brechen reguläre langsame Vorgänge ab; vergleiche sie mit gemessenen Latenzen und passe sie nach Änderungen an.
- Nach 1.000 ms bleibt offen, ob der Anbieter P-731 verarbeitet hat; kläre den Ausgang über die Kennung, nicht per blindem Retry.
- Innere Aufrufe erhalten höchstens das verbleibende Zeitbudget der äußeren Deadline. Ein Abbruch muss weitergereicht und unterstützt werden, damit nachgelagerte Arbeit nach Ablauf der Deadline beendet werden kann.
In der Praxis
- Messpunkt definieren. Lege fest, ob die Grenze Verbindungsaufbau, Antwortbeginn oder vollständige Verarbeitung umfasst. Prüfe, ob Protokoll, Client und Messung denselben Abschnitt betrachten. Das Ergebnis ist eine eindeutige Timeout-Aussage, die später mit Laufzeitdaten verglichen werden kann.
- Gesamtdeadline ableiten. Leite die Ablaufzeit aus dem Antwortziel ab und gib jeder nachgelagerten Operation nur die Restzeit. Bestimme auch, wie abgelaufene Arbeit signalisiert oder fachlich nachverfolgt wird. So bleibt die Gesamtdauer begrenzt, ohne ein neues Budget je Dienst zu starten.
- Abbruch und Ausgang testen. Untersuche, welche Komponenten laufende Arbeit tatsächlich beenden und welche nach einem Timeout weiterarbeiten können. Definiere für letztere Statusabfrage und Wiederaufnahme. Das Ergebnis ist ein belastbarer Umgang mit Ressourcen und ungewissem fachlichem Ausgang.
Ausführliche Erklärung lesen
Ein Timeout definiert die maximale Wartezeit für einen abgegrenzten Schritt. Verbindungsaufbau, Antwortbeginn und vollständige Verarbeitung können eigene Grenzen haben. Für einen zusammengesetzten Ablauf wird eine Deadline weitergereicht, damit nachgelagerte Schritte nur das verbleibende Budget nutzen. Sie ergänzt die Entscheidungen über Synchrone Kommunikation und mögliche Retry.
Das Erreichen eines Timeouts beschreibt zunächst die Beobachtung des Aufrufers. Es bestätigt weder Abbruch beim Empfänger noch Rücknahme einer bereits gespeicherten Wirkung. Abbruchsignale helfen nur, wenn beteiligte Komponenten sie unterstützen. Andernfalls braucht der fachliche Ablauf einen offenen Zustand und eine spätere Statusklärung. Die Wahl der Grenze stützt sich auf Nutzerbedarf und gemessene Latenz, nicht auf eine isolierte Standardzahl.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele der 16 Antworten sind bei 250 ms ungeklärt?
Lösung mit Begründung ansehen
13 von 16: Nur 3 Antworten kommen innerhalb von 250 ms.
AnwendenAuf eine neue Lage übertragen
Der Shop soll bei der Zahlung von B-1042 möglichst wenige ungeklärte Fälle haben, aber höchstens eine Sekunde warten. Welches Budget?
Lösung mit Begründung ansehen
1000 ms: 13 von 16 Antworten kommen rechtzeitig, 3 bleiben ungeklärt. Diese werden als „Zahlung wird geklärt“ behandelt.
BewertenEine Alternative abwägen
Das Team erhöht das Budget auf 3000 ms. Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Vorteil: nur 2 ungeklärte Fälle. Nachteil: Kunde wartet bis zu 3 s und Threads bleiben länger gebunden. Empfehlung: bei 1000 ms bleiben und ungeklärte Fälle sauber nachklären.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- AWS – Timeouts, retries, and backoff with jitter (öffnet in neuem Tab)Erklärt Timeouts, begrenzte Wiederholungen und Jitter anhand verteilter Ausfälle.
- gRPC – Deadlines (öffnet in neuem Tab)Erklärt Zeitbudgets und ihre Weitergabe entlang einer Aufrufkette.
- Google SRE – Handling Overload (öffnet in neuem Tab)Erklärt den Zusammenhang zwischen Überlast, Warteschlangen und begrenzten Ressourcen.