# Eşzamansız bir video üretim API’si ne sıklıkla sorgulanmalı? > Yalnızca durumun değişme olasılığı yüksekken sık sorgulayın; sonra jitter ve üst sınır içeren backoff kullanın. Webhook, sağlayıcı sinyalleri ve durma kurallarını birleştirin. Polling döngüsü sabit bir `sleep` yerine tamamlanma süresi, istek maliyeti ve belirsizliğe göre çalışmalıdır. Beş saniye önizleme için uygun, uzun render için israf olabilir. ## İşin beklenen süresinden başlayın | Beklenen süre | İlk aralık | Sonraki aralık | Kullanım | |---|---:|---:|---| | 30 saniyeden az | 2–4 sn | 5–8 sn | Önizleme | | 30–120 saniye | 4–8 sn | 10–20 sn | Standart | | 2–10 dakika | 10–20 sn | 30–60 sn | Uzun render | | Bilinmiyor | 5 sn | 60 sn’ye kadar backoff | Yeni model | Model ve ayar bazında gözlenen yüzdelikleri kaydedin. Tablo başlangıç noktasıdır, SLA değildir. ## Sabit zamanlayıcı yerine uyarlanabilir backoff kullanın ```text delay = min(max_delay, base_delay * 2^unchanged_rounds) scheduled_delay = delay * random(0.8, 1.2) ``` İlerleme olduğunda sayacı sıfırlayın ve üst sınırı kabul edilebilir bildirim gecikmesinin altında tutun. ## Sağlayıcı sinyallerini yetkili kabul edin | Sinyal | Güvenli eylem | |---|---| | `Retry-After` | Belirtilen süre kadar bekleyin | | Rate limit | Route genelinde backoff | | Kuyrukta | Yavaş sorgulayın | | İşleniyor | Kalan süreye göre planlayın | | Başarılı veya hatalı | Normal polling’i durdurun | | Bilinmeyen iş | Yeniden göndermeden uzlaştırın | ## Webhook ile uzlaştırma polling’ini birleştirin İmzaları doğrulayın, eventleri tekilleştirin ve hızlı yanıtlayın. Yalnızca webhook gelmeyen işleri yavaş sorgulayın. ## Hesabın tamamında eşzamanlılığı sınırlayın Global veya sağlayıcı bütçesi kullanın ve durum kapasitesini yeni submission kapasitesinden ayırın. ## Terk edilmiş ve terminal işleri durdurun Başarı, hata, iptal veya süre bitiminde durun; neden ile remote job ID’yi saklayın. ## Polling verimliliğini ölçün Tamamlanma başına sorgu, algılama gecikmesi, rate limit, çözülmemiş yaş, webhook kapsamı ve backlog’u izleyin. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) metin, görüntü ve video modellerine erişimi birleştirebilir. Durum kuralları route’a özgüdür. ## Sonuç Sağlayıcı önerilerini backoff, jitter, sınırlar ve durma kurallarıyla birleştirin. Webhook bildirir, yavaş polling uzlaştırır. ## FAQ ### İlk polling aralığı ne olmalı? Dokümantasyonu izleyin; öneri yoksa kısa işler için 3–5 saniye temkinli bir başlangıçtır. ### Her iş aynı aralığı mı kullanmalı? Hayır. Beklenen süreyi, yaşı, durumu ve model önerilerini dikkate alın. ### HTTP hatası polling’i durdurur mu? Geçici hataları backoff ile deneyin; açık kimlik doğrulama, doğrulama veya terminal hatalarında durun. ### Webhook tek başına yeterli mi? Gecikebilir veya yinelenebilir; yavaş bir uzlaştırma polling’i bırakın. ### Aynı anda istek dalgası nasıl önlenir? Jitter ekleyin, eşzamanlılığı sınırlayın ve her işi ayrı planlayın. ### Atlas Cloud çok modelli polling’i kolaylaştırır mı? Erişimi birleştirir; ancak durum ve zaman kurallarını uygulama normalize eder.