بما أنّ "واجهة برمجة تطبيقات أحداث Google Workspace" هي خدمة مشترَكة، نفرض حصصًا وقيودًا لضمان استخدامها بشكل عادل من قِبل جميع المستخدمين وحماية الأداء العام لـ Google Workspace.
إذا تجاوزت حصة، ستتلقّى استجابة برمز حالة HTTP هو 429: Too many requests. قد تؤدي عمليات التحقّق الإضافية من الحدّ الأقصى لمعدّل الطلبات في الخلفية على "واجهة برمجة تطبيقات أحداث Google Workspace" أيضًا إلى ظهور استجابة الخطأ نفسها. في حال حدوث هذا الخطأ، استخدِم خوارزمية الرقود الأسي الثنائي وأعِد المحاولة لاحقًا. طالما أنّك تلتزم بالحِصص المحدّدة لكل دقيقة والمدرَجة في الجداول التالية، ليس هناك حدّ لعدد الطلبات التي يمكنك إرسالها يوميًا.
الحِصص لكل مشروع
تحدّ الحِصص لكل مشروع من معدّل طلبات البحث لمشروع على Google Cloud، وبالتالي تنطبق على تطبيق واحد يستدعي طرق "واجهة برمجة تطبيقات أحداث Google Workspace" المحدّدة لكل حصة.
يوضّح الجدول التالي حدود طلبات البحث لكل مشروع. يمكنك أيضًا الاطّلاع على هذه الحدود في صفحة الحِصص في Google Cloud Console.
الحصة لكل مشروع |
طرق "واجهة برمجة تطبيقات أحداث Google Workspace" |
الحدّ |
|---|---|---|
عمليات الكتابة في الدقيقة |
|
600 |
عمليات الكتابة في الدقيقة لكل مستخدم |
|
100 |
عمليات القراءة في الدقيقة |
|
600 |
عمليات القراءة في الدقيقة لكل مستخدم |
|
100 |
حلّ أخطاء الحِصص المستندة إلى الوقت
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (الحدّ الأقصى لعدد N من الطلبات خلال X دقيقة)، ننصحك بأن يرصد الرمز البرمجي الاستثناء ويستخدِم رقودًا أسيًا ثنائيًا مقطوعًا لضمان عدم تحميل أجهزتك حملاً زائدًا.
الرقود الأسي الثنائي هو استراتيجية عادية للتعامل مع الأخطاء في تطبيقات الشبكة. تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات باستخدام أوقات انتظار متزايدة بشكل أسي بين الطلبات، وذلك حتى وقت رقود أقصى. إذا استمرّت الطلبات في الفشل، من المهم أن تزيد حالات التأخير بين الطلبات بمرور الوقت إلى أن ينجح الطلب.
مثال على خوارزمية
تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات بشكل أسي، ما يؤدي إلى زيادة وقت الانتظار بين عمليات إعادة المحاولة حتى وقت رقود أقصى. على سبيل المثال:
- أرسِل طلبًا إلى "واجهة برمجة تطبيقات أحداث Google Workspace".
- إذا تعذّر تنفيذ الطلب، انتظِر 1 +
random_number_millisecondsوأعِد محاولة إرسال الطلب. - إذا تعذّر تنفيذ الطلب، انتظِر 2 +
random_number_millisecondsوأعِد محاولة إرسال الطلب. - إذا تعذّر تنفيذ الطلب، انتظِر 4 +
random_number_millisecondsوأعِد محاولة إرسال الطلب. - وهكذا، حتى وقت
maximum_backoff. - استمِر في الانتظار وإعادة المحاولة حتى عدد أقصى معيّن من عمليات إعادة المحاولة، ولكن لا تزد وقت الانتظار بين عمليات إعادة المحاولة.
حيث:
- وقت الانتظار هو
min(((2^n)+random_number_milliseconds), maximum_backoff), مع زيادةnبمقدار 1 لكل تكرار (طلب). random_number_millisecondsهو عدد عشوائي من الملّي ثوانٍ أقل من أو يساوي 1,000. يساعد ذلك في تجنُّب الحالات التي تتم فيها مزامنة العديد من العملاء في وقت واحد بسبب حالة معيّنة، ويعيدون جميعًا المحاولة في الوقت نفسه، ما يؤدي إلى إرسال الطلبات في موجات متزامنة. تتم إعادة احتساب قيمةrandom_number_millisecondsبعد كل طلب إعادة محاولة.maximum_backoffهو عادةً 32 أو 64 ثانية. تعتمد القيمة المناسبة على حالة الاستخدام.
يمكن للعميل مواصلة إعادة المحاولة بعد أن يصل إلى وقت maximum_backoff.
لا تحتاج عمليات إعادة المحاولة بعد هذه النقطة إلى مواصلة زيادة وقت الرقود. على
سبيل المثال، إذا كان العميل يستخدم وقت maximum_backoff يبلغ 64 ثانية، يمكنه بعد الوصول إلى
هذه القيمة إعادة المحاولة كل 64 ثانية. في مرحلة معيّنة،
يجب منع العملاء من إعادة المحاولة إلى أجل غير مسمّى.
يعتمد وقت الانتظار بين عمليات إعادة المحاولة وعدد عمليات إعادة المحاولة على حالة الاستخدام وظروف الشبكة.
طلب زيادة الحصة لكل مشروع
بناءً على استخدام مشروعك للموارد، قد تحتاج إلى طلب تعديل الحصة تُعتبَر طلبات واجهة برمجة التطبيقات التي يرسلها حساب خدمة مستخدِمة حسابًا واحدًا. لا يضمن التقدم بطلب للحصول على حصة معدَّلة الموافقة. قد تستغرق طلبات تعديل الحصة التي ستؤدي إلى زيادة قيمة الحصة بشكل ملحوظ وقتًا أطول للموافقة عليها.
لا تتساوى الحِصص في جميع المشاريع. مع زيادة استخدامك لـ Google Cloud بمرور الوقت، قد تحتاج إلى زيادة قيم الحِصص. إذا كنت تتوقّع زيادة ملحوظة في الاستخدام في المستقبل القريب، يمكنك طلب تعديلات الحصة بشكل استباقي من صفحة الحِصص في Google Cloud Console.
لمزيد من المعلومات، يُرجى الاطّلاع على المَراجع التالية: