# Hur ofta bör du polla ett asynkront API för videogenerering? > Polla snabbt bara när statusen sannolikt ändras och använd sedan backoff med jitter och tak. Kombinera webhooks, leverantörssignaler och stoppregler. En pollingloop ska styras av sluttid, kostnad och osäkerhet, inte av en fast `sleep`. Fem sekunder kan passa en förhandsvisning men slösa anrop på en lång rendering. ## Börja med jobbets förväntade tid | Förväntad tid | Första intervall | Senare intervall | Användning | |---|---:|---:|---| | Under 30 sekunder | 2–4 s | 5–8 s | Förhandsvisning | | 30–120 sekunder | 4–8 s | 10–20 s | Standard | | 2–10 minuter | 10–20 s | 30–60 s | Lång rendering | | Okänd | 5 s | Backoff upp till 60 s | Ny modell | Spara observerade percentiler per modell och inställning. Tabellen är en startpunkt, inte ett SLA. ## Använd adaptiv backoff i stället för fast timer ```text delay = min(max_delay, base_delay * 2^unchanged_rounds) scheduled_delay = delay * random(0.8, 1.2) ``` Nollställ räknaren vid framsteg och håll taket under acceptabel meddelandefördröjning. ## Behandla leverantörens signaler som styrande | Signal | Säker åtgärd | |---|---| | `Retry-After` | Vänta minst angiven tid | | Rate limit | Backoff för hela rutten | | I kö | Polla långsamt | | Bearbetas | Följ återstående tid | | Klar eller misslyckad | Stoppa normal polling | | Okänt jobb | Stäm av före ny submission | ## Kombinera webhooks med reconciliation polling Validera signaturer, deduplicera events och svara snabbt. Polla bara jobb utan webhook långsamt. ## Begränsa samtidighet för hela kontot Använd en global eller leverantörsspecifik budget och separera kapacitet för status och nya submissions. ## Stoppa övergivna och terminala jobb Stoppa vid framgång, fel, avbokning eller deadline och spara orsak och remote job ID. ## Mät pollingeffektivitet Följ polls per färdigt jobb, upptäcktsfördröjning, rate limits, olöst ålder, webhooktäckning och backlog. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) kan samla åtkomst till text-, bild- och videomodeller. Statusregler är fortfarande ruttspecifika. ## Slutsats Kombinera leverantörens råd med backoff, jitter, gränser och stoppregler. Webhooks meddelar och långsam polling stämmer av. ## FAQ ### Vilket första intervall är rimligt? Följ dokumentationen; utan råd är 3–5 sekunder en försiktig start för korta jobb. ### Ska alla jobb ha samma intervall? Nej. Ta hänsyn till väntad tid, ålder, status och modellens råd. ### Stoppar ett HTTP-fel polling? Försök igen vid tillfälliga fel med backoff och stoppa vid tydliga autentiserings-, validerings- eller terminalfel. ### Räcker webhooks? De kan försenas eller dupliceras, så behåll långsam reconciliation polling. ### Hur undviker man en samtidig pollvåg? Lägg till jitter, begränsa samtidighet och planera varje jobb separat. ### Förenklar Atlas Cloud multimodell-polling? Åtkomsten kan samlas, men appen normaliserar status och timing per modell.