# كم مرة يجب استطلاع واجهة API غير متزامنة لتوليد الفيديو؟ > استطلع بسرعة فقط في الفترة التي يُرجح أن تتغير فيها الحالة، ثم استخدم backoff مع jitter وحد أقصى. اجمع بين webhook وإشارات المزود وقواعد توقف واضحة. يجب أن تعتمد حلقة polling على وقت الاكتمال وكلفة الطلب وعدم اليقين، لا على `sleep` ثابت. قد تناسب خمس ثوانٍ معاينة قصيرة لكنها تهدر الطلبات في render طويل. ## ابدأ بالمدة المتوقعة للمهمة | المدة المتوقعة | الفاصل الأول | الفاصل اللاحق | الاستخدام | |---|---:|---:|---| | أقل من 30 ثانية | 2–4 ثوانٍ | 5–8 ثوانٍ | معاينة | | 30–120 ثانية | 4–8 ثوانٍ | 10–20 ثانية | توليد عادي | | 2–10 دقائق | 10–20 ثانية | 30–60 ثانية | render طويل | | غير معروفة | 5 ثوانٍ | Backoff حتى 60 ثانية | نموذج جديد | خزّن النسب المئوية المقاسة لكل نموذج وإعداد. الجدول نقطة بداية وليس SLA. ## استخدم backoff تكيفياً بدلاً من مؤقت ثابت ```text delay = min(max_delay, base_delay * 2^unchanged_rounds) scheduled_delay = delay * random(0.8, 1.2) ``` صفّر العداد عند وجود تقدم واجعل الحد الأقصى أقل من تأخر الإشعار المقبول. ## اعتبر إشارات المزود مرجعاً أساسياً | الإشارة | الإجراء الآمن | |---|---| | `Retry-After` | الانتظار للمدة المحددة على الأقل | | Rate limit | Backoff للمسار كله | | في قائمة الانتظار | Polling بطيء | | قيد المعالجة | الجدولة قرب الوقت المتبقي | | نجاح أو فشل | إيقاف polling العادي | | مهمة مجهولة | المطابقة قبل إعادة الإرسال | ## اجمع بين webhook وpolling المطابقة تحقق من التوقيع وأزل الأحداث المكررة واستجب بسرعة. استطلع ببطء المهام التي لم يصل لها webhook فقط. ## ضع حداً للتزامن على مستوى الحساب استخدم ميزانية عامة أو لكل مزود وافصل سعة فحص الحالة عن سعة submissions الجديدة. ## أوقف المهام المهجورة والنهائية توقف عند النجاح أو الفشل أو الإلغاء أو انقضاء المهلة، واحفظ السبب وremote job ID. ## قِس كفاءة polling تتبع عدد عمليات poll لكل اكتمال وتأخر الاكتشاف وrate limits وعمر المهام غير المحلولة وتغطية webhook وbacklog. يستطيع [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) توحيد الوصول إلى نماذج النص والصورة والفيديو. تبقى قواعد الحالة خاصة بكل route. ## الخلاصة اجمع إرشادات المزود مع backoff وjitter وحدود التزامن وقواعد التوقف. يبلغ webhook، وتتكفل polling البطيئة بالمطابقة. ## FAQ ### ما الفاصل الأول المناسب؟ اتبع توثيق المزود؛ وعند غيابه تمثل 3 إلى 5 ثوان بداية حذرة للمهمة القصيرة. ### هل تستخدم كل المهام الفاصل نفسه؟ لا. راعِ المدة المتوقعة وعمر المهمة وحالتها وإرشادات النموذج. ### هل يوقف خطأ HTTP عملية polling؟ أعد محاولة الأخطاء المؤقتة مع backoff، وتوقف عند أخطاء المصادقة أو التحقق أو الحالة النهائية الواضحة. ### هل يكفي webhook وحده؟ قد يتأخر أو يتكرر، لذلك احتفظ بعملية polling بطيئة للمطابقة. ### كيف نتجنب موجة طلبات متزامنة؟ أضف jitter وحدود concurrency وجدولاً مستقلاً لكل مهمة. ### هل يبسط Atlas Cloud polling متعدد النماذج؟ يمكنه توحيد الوصول، لكن التطبيق يظل مسؤولاً عن توحيد الحالات والتوقيت.