حدود المعدل

تفرض Google Ads API الحدّ الأقصى لعدد الطلبات من خلال عدد طلبات البحث في الثانية على كلّ من أرقام تعريف العملاء ومشاريع Google Cloud بشكلٍ مستقل. تستخدِم Google Ads API خوارزمية حزمة الرموز المميزة لقياس الطلبات وتحديد حدّ مناسب لعدد الطلبات في الثانية، وبالتالي سيختلف الحدّ الدقيق حسب إجمالي حِمل الخادم في أي وقت معيّن.

الغرض من فرض حدود المعدّل هو منع مستخدم واحد من تعطيل الخدمة للمستخدمين الآخرين (سواء كان ذلك عن قصد أو عن غير قصد) من خلال إرسال عدد كبير من الطلبات إلى خوادم "واجهة برمجة التطبيقات" في "إعلانات Google".

سيتم رفض الطلبات التي تخالف حدود المعدّل مع ظهور الخطأ: RESOURCE_TEMPORARILY_EXHAUSTED.

يمكنك التحكّم في تطبيقك والحدّ من القيود المفروضة على المعدّل من خلال تقليل عدد الطلبات بشكل نشط والحدّ من عدد الطلبات في الثانية من جهة العميل.

هناك عدد من الطرق لتقليل فرص تجاوز الحدّ الأقصى للمعدّل. يمكن أن يساعدك التعرّف على مفاهيم أنماط تكامل المؤسسات (EIP)، مثل المراسلة وإعادة التسليم والتقييد، في إنشاء تطبيق عميل أكثر فعالية.

في ما يلي الممارسات المقترَحة مرتّبة حسب درجة التعقيد، بدءًا بالاستراتيجيات الأبسط ثم التصاميم الأكثر فعالية ولكنها أكثر تعقيدًا:

الحدّ من المهام المتزامنة

أحد الأسباب الجذرية لتجاوز حدود المعدّل هو أنّ تطبيق العميل ينشئ عددًا كبيرًا من المهام المتوازية. على الرغم من أنّنا لا نفرض أي قيود على عدد الطلبات المتوازية التي يمكن أن يقدّمها تطبيق العميل، إلا أنّ هذا العدد قد يتجاوز الحدّ الأقصى للطلبات في الثانية على مستوى مشروع Google Cloud.

ننصحك بضبط حدّ أعلى معقول لإجمالي عدد المهام المتزامنة التي ستُرسِل طلبات (على مستوى جميع العمليات والأجهزة)، وتعديل الحدّ الأعلى لتحسين سرعة معالجة البيانات بدون تجاوز الحدّ الأقصى المسموح به.

بالإضافة إلى ذلك، يمكنك الحدّ من عدد طلبات البحث في الثانية من جهة العميل (راجِع الحدّ من عدد طلبات البحث في الثانية وأدوات الحدّ من المعدّل).

تجميع الطلبات

ننصحك بتجميع عمليات متعددة في طلب واحد. وينطبق ذلك بشكل كبير على مكالمات Mutate التي يتم إجراؤها للحصول على خدمات مختلفة. على سبيل المثال، إذا كنت بصدد تعديل الحالة لعدة مثيلات من AdGroupAd، يمكنك استدعاء MutateAdGroupAds مرة واحدة، وتمرير عدة operations بدلاً من استدعاء MutateAdGroupAds مرة واحدة لكل AdGroupAd. يمكنك الرجوع إلى إرشادات العمليات المجمّعة للاطّلاع على بعض الأمثلة الإضافية.

في حين أنّ تجميع الطلبات يقلّل من إجمالي عدد الطلبات ويخفّف من حدود المعدّل على الطلبات في الدقيقة، قد يؤدي إلى تجاوز حد المعدّل للعمليات في الدقيقة إذا أجريت عددًا كبيرًا من العمليات على حساب واحد.

الحدّ من المعدّل وأدوات الحدّ من المعدّل

بالإضافة إلى الحدّ من إجمالي عدد سلاسل المحادثات في تطبيقك، يمكنك أيضًا تنفيذ أدوات تحديد المعدّل على جهة العميل. يمكن أن يضمن ذلك أن تخضع جميع سلاسل المحادثات في عملياتك و / أو مجموعاتك لحدّ معيّن لعدد طلبات البحث في الثانية من جهة العميل.

يمكنك الاطّلاع على Guava Rate Limiter، أو تنفيذ خوارزمية حزمة الرموز المميزة الخاصة بك في بيئة مجمّعة. على سبيل المثال، يمكنك إنشاء رموز مميّزة وتخزينها في مساحة تخزين مشتركة للمعاملات، مثل قاعدة بيانات، وسيحتاج كل عميل إلى الحصول على رمز مميّز واستخدامه قبل معالجة الطلب. إذا تم استخدام جميع الرموز المميزة، على العميل الانتظار إلى أن يتم إنشاء المجموعة التالية من الرموز المميزة.

الإضافة إلى قائمة المحتوى التالي

قائمة انتظار الرسائل هي الحلّ لتوزيع عبء العمليات، مع التحكّم أيضًا في معدّلات الطلبات والمستهلكين. تتوفّر عدة خيارات لقوائم انتظار الرسائل، بعضها مفتوح المصدر وبعضها خاص، ويمكن استخدام العديد منها مع لغات مختلفة.

عند استخدام قوائم انتظار الرسائل، يمكنك أن يكون لديك العديد من المنتجين الذين يرسلون الرسائل إلى قائمة الانتظار والعديد من المستهلكين الذين يعالجون هذه الرسائل. يمكن تنفيذ عمليات التقييد من جهة المستهلك من خلال الحدّ من عدد المستهلكين المتزامنين، أو تنفيذ أدوات تحديد المعدّل أو أدوات التقييد لكل من المنتجين أو المستهلكين.

على سبيل المثال، إذا واجه مستهلك رسالة خطأ في الحدّ الأقصى للمعدّل، يمكنه إعادة الطلب إلى قائمة الانتظار لإعادة المحاولة. في الوقت نفسه، يمكن للمستهلك إبلاغ جميع المستهلكين الآخرين بإيقاف المعالجة مؤقتًا لعدد من الثواني من أجل التعافي من الخطأ.