القيود على المعدل
تُصنّف واجهة برمجة التطبيقات Google Ads API طلبات الحدّ من المعدّل حسب عدد طلبات البحث في الثانية لكل رقم تعريف عميل (CID) ورمز مميز للمطوِّر، ما يعني أنّ القياس يتم بشكل مستقل على كلّ من أرقام تعريف العملاء والرموز المميزة للمطوِّرين. تستخدم واجهة برمجة التطبيقات Google Ads API خوارزمية مجموعة الرموز المميزة لقياس الطلبات وتحديد حدّ مناسب لعدد الطلبات في الثانية، لذا سيختلف الحدّ الدقيق حسب إجمالي حمل الخادم في أي وقت معيّن.
الغرض من فرض حدود المعدّل هو منع مستخدم واحد من تعطيل الخدمة للمستخدمين الآخرين من خلال (إما عن قصد أو عن غير قصد) إغراق خوادم "واجهة برمجة التطبيقات لإعلانات Google" بعدد كبير من الطلبات.
سيتم رفض الطلبات التي تنتهك حدود معدّل الاستخدام مع ظهور الخطأ:
RESOURCE_TEMPORARILY_EXHAUSTED.
يمكنك التحكّم في تطبيقك والحدّ من معدّل الطلبات من خلال تقليل عدد الطلبات بشكل نشط وتقييد عدد الطلبات في الثانية من جهة العميل.
هناك عدد من الطرق لتقليل فرص تجاوز الحدّ الأقصى لعدد الطلبات. يمكن أن يساعدك التعرّف على مفاهيم أنماط دمج المؤسسات (EIP)، مثل المراسلة وإعادة التسليم والتقييد، في إنشاء تطبيق عميل أكثر فعالية.
في ما يلي الممارسات المقترَحة مرتّبة حسب درجة التعقيد، مع وضع الاستراتيجيات الأبسط في الأعلى والتصاميم الأكثر فعالية وتعقيدًا في الأسفل:
- الحدّ من المهام المتزامنة
- تجميع الطلبات
- الحدّ من الاستخدام ومحددات المعدّل
- وضع المحتوى في قائمة الانتظار
الحدّ من المهام المتزامنة
أحد الأسباب الجذرية لتجاوز حدود المعدّل هو أنّ تطبيق العميل ينشئ عددًا كبيرًا من المهام المتوازية. على الرغم من أنّنا لا نضع حدًا لعدد الطلبات المتوازية التي يمكن أن يقدّمها تطبيق العميل، يمكن أن يتجاوز هذا العدد بسهولة الحدّ الأقصى لعدد الطلبات في الثانية على مستوى رمز المطوّر.
ننصحك بضبط حدّ أعلى معقول لإجمالي عدد المهام المتزامنة التي ستُرسل طلبات (على مستوى جميع العمليات والأجهزة)، وتعديل الحدّ الأعلى لتحسين معدل النقل بدون تجاوز الحدّ الأقصى المسموح به.
بالإضافة إلى ذلك، يمكنك الحدّ من عدد طلبات البحث في الثانية من جهة العميل (راجِع الحدّ من عدد طلبات البحث في الثانية وأدوات الحدّ من المعدّل).
تجميع الطلبات
ننصحك بتجميع عمليات متعددة في طلب واحد. وينطبق ذلك بشكل خاص على مكالمات MutateFoo. على سبيل المثال، إذا كنت تعدّل الحالة لعدة مثيلات من AdGroupAd، يمكنك استدعاء MutateAdGroupAds مرة واحدة وتمرير عدة operations بدلاً من استدعاء MutateAdGroupAds مرة واحدة لكل AdGroupAd. يمكنك الرجوع إلى إرشادات عمليات الدفعات
للاطّلاع على بعض الأمثلة الإضافية.
في حين أنّ تجميع الطلبات يقلّل من إجمالي عدد الطلبات ويخفّف من حدّ معدّل الطلبات في الدقيقة، قد يؤدي إلى تجاوز حدّ معدّل العمليات في الدقيقة إذا أجريت عددًا كبيرًا من العمليات على حساب واحد.
الحدّ من الاستخدام ومحددات المعدّل
بالإضافة إلى الحدّ من العدد الإجمالي لسلاسل المحادثات في تطبيق العميل، يمكنك أيضًا تنفيذ أدوات الحدّ من المعدّل على مستوى العميل. يمكن أن يضمن ذلك أن تخضع جميع سلاسل المحادثات في عملياتك و / أو مجموعاتك لحدّ معيّن لعدد طلبات البحث في الثانية من جهة العميل.
يمكنك الاطّلاع على Guava Rate Limiter أو تنفيذ خوارزمية Token Bucket الخاصة بك لبيئة مجمّعة. على سبيل المثال، يمكنك إنشاء رموز مميّزة وتخزينها في مساحة تخزين مشتركة للمعاملات، مثل قاعدة بيانات، وسيحتاج كل عميل إلى الحصول على رمز مميّز واستخدامه قبل معالجة الطلب. إذا تم استخدام جميع الرموز المميزة، على العميل الانتظار إلى أن يتم إنشاء المجموعة التالية من الرموز المميزة.
الإضافة إلى قائمة المحتوى التالي
قائمة انتظار الرسائل هي الحلّ لتوزيع عبء العمليات، مع التحكّم أيضًا في معدّلات الطلبات والمستهلكين. تتوفّر عدة خيارات لقوائم انتظار الرسائل، بعضها مفتوح المصدر وبعضها خاص، ويمكن استخدام العديد منها مع لغات مختلفة.
عند استخدام قوائم انتظار الرسائل، يمكنك أن يكون لديك العديد من المنتجين الذين يرسلون الرسائل إلى قائمة الانتظار والعديد من المستهلكين الذين يعالجون هذه الرسائل. يمكن تنفيذ عمليات التقييد من جهة المستهلك عن طريق الحدّ من عدد المستهلكين المتزامنين، أو تنفيذ أدوات تقييد المعدّل أو أدوات التقييد لكل من المنتجين أو المستهلكين.
على سبيل المثال، إذا واجه مستهلك رسالة خطأ في الحدّ الأقصى للمعدّل، يمكنه إعادة الطلب إلى قائمة الانتظار لإعادة المحاولة. في الوقت نفسه، يمكن للمستهلك إبلاغ جميع المستهلكين الآخرين بإيقاف المعالجة مؤقتًا لعدد من الثواني من أجل التعافي من الخطأ.