راقب استخدام مفتاحك قبل أن تبلغ الحد
متابعة ترويسات الحصة أولًا بأول تخبرك متى يقترب الحد، قبل وقت طويل من رفض أي طلب فعليًا.
قيمة المهلة التي تعمل جيدًا مع استعلام عنوان واحد ستقطع طلبًا مجمّعًا يحمل بضعة آلاف من العناصر قبل وقت طويل من انتهاء الخادم من معالجتها كلها، وهو ما يبدو فشلًا مع أن الطلب كان سيكتمل لو أُعطي الوقت الكافي.
كل عنصر في المصفوفة المجمّعة استعلام قائم بذاته، لذا فإن طلبًا يحتوي على 2,000 عنصر ينطوي على ما يقارب 2,000 ضعف معالجة الاستعلام الواحد، رغم أنه استدعاء HTTP واحد من جهتك. ومهلة ثانية أو ثانيتين، المعقولة لعنوان واحد، لا تكفي أبدًا لطلب بهذا الحجم.
اضبط مهلة العميل لديك بما يتناسب مع حجم المصفوفة التي ترسلها، مع هامش للتفاوت المعتاد، بدلًا من استخدام قيمة ثابتة واحدة لكل الطلبات التي تجريها شيفرتك، صغيرة كانت أم كبيرة.
timeout_seconds = max(5, item_count * 0.05)هذه نقطة انطلاق تضبطها وفق السلوك الذي تلاحظه بنفسك، لا رقم ثابت تتعامل معه كمرجع نهائي، لأن زمن المعالجة الفعلي لكل عنصر ليس ضمانًا منشورًا.
بدلًا من رفع قيم المهلة أكثر فأكثر لاستيعاب طلب واحد يزداد حجمه باستمرار، قسّم المهمة الكبيرة جدًا إلى أجزاء يضم كل منها من بضع مئات إلى بضعة آلاف من العناصر. فالأجزاء الأصغر تحتاج إلى مهلات أقصر ويمكن التنبؤ بها أكثر، والفشل في منتصف الطريق لا يكلفك إلا الجزء الحالي بدلًا من المهمة كلها.
إذا انتهت مهلة طلب ما من جهتك، فقد لا تعرف ما إذا كان الخادم قد أنهى معالجته فعلًا أم لا. وبدلًا من إعادة إرسال الجزء نفسه دون تفكير، وهو ما قد يؤدي إلى احتسابه مرتين من حصتك إذا كان الطلب الأصلي قد اكتمل، راجع ترويسات الحصة من آخر استدعاء ناجح لتقدّر ما إذا كان الجزء الذي انتهت مهلته قد مرّ على الأرجح، ثم أعد الإرسال بحذر.
المهلة إعداد من جانب العميل فقط يحدد المدة التي تقبل انتظارها. ولا أثر لها في تكلفة الطلب، التي تبقى طلبًا واحدًا لكل عنصر تمت معالجته، سواء انتظر العميل المدة كاملة أو توقف مبكرًا.
مواءمة المهلة مع حجم الدفعة، وتفضيل عدة أجزاء أصغر على طلب واحد كبير جدًا، يجعلان المهام الكبيرة موثوقة وسهلة الاستئناف إذا حدث خطأ ما. ويتناول توثيق حدود معدل الطلبات استراتيجية التقسيم والحصة للمهام الكبيرة بتفصيل أكبر.