بما أنّ Google Workspace Events API هي خدمة مشترَكة، نطبّق حصصًا ومقيّدات للتأكّد من استخدامها بشكل عادل من قِبل جميع المستخدمين ولحماية الأداء الإجمالي لخدمة Google Workspace.
إذا تجاوزت الحصة، ستتلقّى استجابة رمز حالة HTTP 429: Too many requests
. قد تؤدي عمليات التحقّق الإضافية من الحد الأقصى للمعدل في الخلفية في Google Workspace Events API إلى ظهور الردّ على الخطأ نفسه. في حال حدوث هذا الخطأ، عليك استخدام خوارزمية التوقف المؤقت المتزايد
وإعادة المحاولة لاحقًا. ما دامت الطلبات ضمن الحصص المحدّدة لكل دقيقة والمدرَجة في
الجداول التالية، ليس هناك حدّ أقصى لعدد الطلبات التي يمكنك إجراؤها
في اليوم.
الحصص لكل مشروع
تحدّ الحصص لكل مشروع من معدّل طلبات البحث لمشروع على Google Cloud، وبالتالي تنطبق على تطبيق واحد يستدعي طُرق Google Workspace Events API المحدّدة لكل حصة.
يوضّح الجدول التالي الحدود القصوى لطلبات البحث لكل مشروع. يمكنك أيضًا العثور على هذه الحدود في صفحة الحصص في وحدة تحكّم Google Cloud.
الحصة لكل مشروع |
طرق Google Workspace Events API |
الحدّ |
---|---|---|
عدد الكتابات في الدقيقة |
|
600 |
عمليات الكتابة في الدقيقة لكل مستخدم |
|
100 |
عدد القراءات في الدقيقة |
|
600 |
عدد القراءات في الدقيقة لكل مستخدم |
|
100 |
حلّ أخطاء الحصة المستندة إلى الوقت
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (الحد الأقصى لطلبات N كل X دقائق)، ننصح بأن يرصد الرمز البرمجي الاستثناء ويستخدم وقت انتظار متزايد مقطوع للتأكّد من عدم توليد أجهزتك لحمل زائد.
إنّ التأخير المتزايد هو استراتيجية معالجة أخطاء عادية لتطبيقات الشبكة. تعيد خوارزمية التراجع الأسي الطلبات باستخدام أوقات انتظار متزايدة بشكل تصاعدي بين الطلبات، حتى الحد الأقصى لوقت التراجع. إذا استمرت الطلبات غير ناجحة، من المهم زيادة فترات التأخير بين الطلبات بمرور الوقت إلى أن يصبح الطلب ناجحًا.
مثال على الخوارزمية
تعيد خوارزمية التراجع الأسي الطلبات بشكلٍ أسي، ما يؤدي إلى زيادة وقت الانتظار بين عمليات إعادة المحاولة إلى الحد الأقصى لوقت التراجع. على سبيل المثال:
- قدِّم طلبًا إلى Google Workspace Events API.
- إذا تعذّر إكمال الطلب، انتظِر
random_number_milliseconds
ثانية ثم أعِد محاولة إكماله. - إذا تعذّر إكمال الطلب، انتظِر
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.
لمزيد من المعلومات، يُرجى الاطّلاع على المراجع التالية: