تفرض Google Ads API حدًّا أقصى لعدد الطلبات في الثانية (QPS) على كلّ من أرقام تعريف العملاء ومشاريع Google Cloud بشكل مستقل. بالإضافة إلى الطلبات في الدقيقة (التي تقيس معدّل تكرار طلبات البيانات من واجهة برمجة التطبيقات)، تفرض Google Ads API أيضًا حدودًا على العمليات في الدقيقة (التي تقيس إجمالي عدد عمليات واجهة برمجة التطبيقات على مستوى الطلبات). تستخدم Google Ads API خوارزمية حزمة الرموز المميزة لقياس الطلبات وتحديد حدّ مناسب لعدد طلبات البحث في الثانية، لذا يختلف الحدّ الدقيق حسب إجمالي حمولة الخادم في أي وقت.
الغرض من فرض حدود المعدّل هو منع مستخدم واحد من تعطيل الخدمة للمستخدمين الآخرين من خلال إغراق خوادم Google Ads API بعدد كبير من الطلبات (سواء عن قصد أو عن غير قصد).
يتم رفض الطلبات التي تخالف حدود المعدّل مع ظهور رسالة الخطأ:
RESOURCE_TEMPORARILY_EXHAUSTED.
يمكنك التحكّم في تطبيقك والحدّ من معدّلات الطلبات من خلال تقليل عدد الطلبات بشكل نشط والحدّ من عدد الطلبات في الثانية من جهة العميل.
هناك عدة طرق لتقليل فرص تجاوز الحد الأقصى المسموح به للمعدّل. يمكنك إنشاء تطبيق عميل أكثر فعالية من خلال التعرّف على مفاهيم أنماط دمج المؤسسات (EIP)، مثل المراسلة وإعادة التسليم والتحكّم في السرعة.
يتم ترتيب الممارسات المقترَحة التالية حسب درجة التعقيد، مع وضع الاستراتيجيات الأبسط في الأعلى، تليها البُنى الأكثر قوة وتعقيدًا:
- الانتظار الأسي
- الحدّ من المهام المتزامنة
- تجميع الطلبات
- Throttling and rate limiters
- الانتظار في قائمة الانتظار
الرقود الأسي الثنائي
عندما يتلقّى تطبيقك الخطأ
RESOURCE_TEMPORARILY_EXHAUSTED، استخدِم سياسة تأخير أسي مع تفاوت عشوائي قبل إعادة محاولة إرسال الطلب الذي تعذّر إكماله. تزيد خوارزمية الرقود الأسي الثنائي وقت الانتظار بين
عمليات إعادة المحاولة تدريجيًا (على سبيل المثال، الانتظار لمدة ثانيتين، ثم 4 ثوانٍ، ثم 8 ثوانٍ، بالإضافة إلى
تأخير عشوائي بسيط)، ما يسمح باستعادة حمولة الخادم وحصص الاستخدام مع
منع الارتفاعات المفاجئة في عمليات إعادة المحاولة المتزامنة على مستوى نُسخ العميل.
الحدّ من المهام المتزامنة
أحد الأسباب الأساسية لتجاوز حدود المعدّل هو أنّ تطبيق العميل ينشئ عددًا مفرطًا من المهام المتوازية. مع أنّنا لا نحدّ من عدد الطلبات المتزامنة التي يمكن أن يرسلها تطبيق العميل، قد يتجاوز ذلك الحدّ الأقصى لعدد الطلبات في الثانية على مستوى مشروع Google Cloud.
ننصحك بضبط حدّ أقصى معقول لإجمالي عدد المهام المتزامنة التي ستُرسل الطلبات (على مستوى جميع العمليات والأجهزة)، وتعديله للأعلى لتحسين معدّل النقل بدون تجاوز الحدّ الأقصى المسموح به.
بالإضافة إلى ذلك، يمكنك النظر في تقييد عدد طلبات البحث في الثانية من جهة العميل (راجِع التقييد ومحدِّدات المعدّل).
تجميع الطلبات
ننصحك بتجميع عمليات متعددة في طلب واحد. ينطبق ذلك في الغالب على المكالمات التي يتم إجراؤها على Mutate لخدمات مختلفة. على سبيل المثال، إذا كنت تعدّل الحالة لعدة نُسخ من AdGroupAd، يمكنك استدعاء MutateAdGroupAds مرة واحدة، وتمرير عدة operations بدلاً من استدعاء MutateAdGroupAds مرة واحدة لكل AdGroupAd. يمكنك الرجوع إلى إرشادات العمليات المجمّعة للاطّلاع على بعض الأمثلة الإضافية.
على الرغم من أنّ تجميع الطلبات يقلّل من إجمالي عدد طلبات البيانات من واجهة برمجة التطبيقات ويخفّف من حدود معدّل الطلبات في الدقيقة، قد يؤدي ذلك إلى تفعيل حدّ معدّل العمليات في الدقيقة إذا نفّذت عددًا كبيرًا من العمليات في حساب واحد.
التقييد ومحدِّدات المعدّل
بالإضافة إلى الحدّ من إجمالي عدد سلاسل المحادثات في تطبيقك، يمكنك أيضًا تنفيذ محدّدات معدّل الاستخدام على جانب العميل. يضمن ذلك أن تكون جميع سلاسل المحادثات في جميع العمليات أو المجموعات أو كليهما خاضعة لحدّ معيّن من طلبات البحث في الثانية من جهة العميل.
يمكنك الاطّلاع على Guava RateLimiter أو تنفيذ خوارزمية حزمة الرموز المميزة الخاصة بك لبيئة مجمّعة. على سبيل المثال، يمكنك إدارة الرموز المميّزة في مخزن بيانات موزَّع في الذاكرة بزمن انتقال منخفض، مثل Redis أو Memcached، حيث يحصل كل عميل على رمز مميّز ويستخدمه قبل معالجة الطلب. إذا نفدت الرموز المميّزة، ينتظر العميل حتى يتم تجديد الدفعة التالية من الرموز المميّزة.
الإضافة إلى قائمة المحتوى التالي
تُعدّ قائمة انتظار الرسائل الحلّ الأمثل لتوزيع عبء العمليات، مع التحكّم أيضًا في معدّلات الطلبات والمستهلكين. هناك عدد من خيارات قائمة انتظار الرسائل المتاحة، بعضها برنامج مفتوح المصدر وبعضها مملوك، ويمكن للعديد منها العمل بلغات مختلفة.
عند استخدام قوائم انتظار الرسائل، يمكنك أن يكون لديك العديد من المنتجين الذين يدفعون الرسائل إلى قائمة الانتظار والعديد من المستهلكين الذين يعالجون هذه الرسائل. يمكن تنفيذ عمليات التقييد على جانب المستهلك عن طريق الحد من عدد المستهلكين المتزامنين، أو عن طريق تنفيذ محددات المعدل أو المخنقين للمنتجين أو المستهلكين.
على سبيل المثال، إذا واجه مستهلك الرسائل خطأً في الحد الأقصى للمعدّل، يمكنه إعادة الطلب إلى قائمة الانتظار مع تأخير موحّد لإعادة المحاولة (باستخدام العودة الأسيّة) وتعديل تقرير الملاحظات والآراء المشترك للحدّ من المعدّل لكي يقلّل جميع المستهلكين معدّل المعالجة تلقائيًا أثناء التعافي من الخطأ.