# Wie oft sollte eine asynchrone Video-API abgefragt werden? > Fragen Sie nur in der kurzen wahrscheinlichen Änderungsphase schnell ab und nutzen Sie danach Backoff mit Jitter und Obergrenze. Kombinieren Sie Webhooks, Provider-Signale und klare Abbruchregeln. Ein Polling-Loop sollte sich an Fertigstellungszeit, Anfragekosten und Unsicherheit orientieren, nicht an einem festen `sleep`. Fünf Sekunden können für eine Vorschau passen und bei mehrminütigen Renderings verschwenderisch sein. ## Mit der erwarteten Jobdauer beginnen | Erwartete Dauer | Erstes Intervall | Späteres Intervall | Einsatz | |---|---:|---:|---| | Unter 30 Sekunden | 2 bis 4 s | 5 bis 8 s | Vorschau | | 30 bis 120 Sekunden | 4 bis 8 s | 10 bis 20 s | Standard | | 2 bis 10 Minuten | 10 bis 20 s | 30 bis 60 s | Langes Rendering | | Unbekannt | 5 s | Backoff bis 60 s | Neues Modell | Speichern Sie gemessene Perzentile je Modell und Konfiguration. Die Tabelle ist ein Startwert, kein SLA. ## Adaptives Backoff statt festem Timer verwenden ```text delay = min(max_delay, base_delay * 2^unchanged_rounds) scheduled_delay = delay * random(0.8, 1.2) ``` Setzen Sie den Zähler bei Fortschritt zurück und halten Sie die Obergrenze unter der tolerierbaren Benachrichtigungsverzögerung. ## Provider-Signale als maßgeblich behandeln | Signal | Sichere Aktion | |---|---| | `Retry-After` | Mindestens so lange warten | | Rate Limit | Route global zurücknehmen | | In Warteschlange | Langsam pollen | | In Bearbeitung | Restzeit berücksichtigen | | Erfolg oder Fehler | Normales Polling stoppen | | Unbekannter Job | Vor erneutem Senden abgleichen | ## Webhooks mit Reconciliation-Polling kombinieren Prüfen Sie Signaturen, deduplizieren Sie Events und antworten Sie schnell. Nur fehlende Webhooks werden langsam abgeglichen. ## Parallelität des gesamten Kontos begrenzen Setzen Sie ein globales oder providerspezifisches Budget und trennen Sie Kapazität für Statusabfragen und neue Einreichungen. ## Verlassene und finale Jobs stoppen Stoppen Sie bei Erfolg, Fehler, Abbruch oder Fristende und speichern Sie Grund und Remote-Job-ID. ## Polling-Effizienz messen Messen Sie Polls pro Abschluss, Erkennungsverzug, Rate Limits, ungelöstes Alter, Webhook-Abdeckung und Backlog. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) kann Zugriffe auf Text-, Bild- und Videomodelle vereinheitlichen. Zustandsregeln bleiben modellspezifisch. ## Fazit Kombinieren Sie Provider-Vorgaben, Backoff, Jitter, Parallelitätsgrenzen und Stoppregeln. Webhooks benachrichtigen, langsames Polling gleicht ab. ## FAQ ### Welches erste Intervall ist sinnvoll? Befolgen Sie die Provider-Dokumentation; ohne Vorgabe sind bei kurzen Jobs 3 bis 5 Sekunden ein vorsichtiger Start. ### Soll jeder Job dasselbe Intervall nutzen? Nein. Erwartete Dauer, Alter, Zustand und Modellhinweise müssen berücksichtigt werden. ### Stoppt ein HTTP-Fehler das Polling? Transiente Fehler werden mit Backoff wiederholt; klare Authentifizierungs-, Validierungs- und Endzustandsfehler stoppen es. ### Reichen Webhooks aus? Wegen Verzögerung oder Duplikaten bleibt langsames Reconciliation-Polling sinnvoll. ### Wie verhindert man gleichzeitige Poll-Wellen? Nutzen Sie Jitter, Parallelitätsgrenzen und unabhängige Zeitpläne je Job. ### Vereinfacht Atlas Cloud Multi-Modell-Polling? Der Zugriff kann vereinheitlicht werden, Zustände und Zeiten normalisiert weiterhin die Anwendung.