بما أنّ Google Chat API هي خدمة مشتركة، نطبّق الحصص والقيود لضمان استخدام جميع المستخدمين لها بشكل عادل وحماية الأداء العام في خدمات Google Workspace.
وإذا تجاوزت إحدى الحصص، ستتلقّى استجابة رمز حالة HTTP 429: Too many requests
. قد تؤدي أيضًا عمليات التحقق الإضافية للحدّ من الأسعار على
الخلفية في Chat إلى ظهور استجابة الخطأ نفسها. إذا حدث هذا الخطأ، يجب عليك استخدام خوارزمية الرقود الأسي وإعادة المحاولة لاحقًا. وما دمت تبقى ضمن الحصص المحدّدة لكل دقيقة والمذكورة في الجداول التالية، ليس هناك حد أقصى لعدد الطلبات التي يمكنك تقديمها يوميًا.
ينطبق نوعان من الحصص على طرق Chat API، وهما: الحصص لكل مساحة وحصص لكل مشروع.
الحصص لكلّ مساحة
تحدّ الحصص لكلّ مساحة من معدّل طلبات البحث في مساحة معيّنة، وتتم مشاركتها بين جميع تطبيقات Chat القائمة على طلبات البيانات من خلال طُرق Chat API المدرَجة لكل حصة.
تفاصيل الجدول التالي حول حدود طلبات البحث لكل مساحة:
الحصة لكل مساحة |
طرق Chat API |
الحدّ الأقصى المسموح به (لكل 60 ثانية، تتم مشاركته |
---|---|---|
عدد مرّات القراءة في الدقيقة |
|
900 |
الكتابة في الدقيقة |
|
60 |
الحصص لكل مشروع
تحد الحصص لكل مشروع من معدل طلبات البحث لمشروع Google Cloud، وبالتالي تنطبق على تطبيق Chat واحد يستدعي طُرق Chat API المحدّدة لكل حصة.
تفاصيل الجدول التالي حدود طلبات البحث لكل مشروع يمكنك أيضًا العثور على هذه الحدود في صفحة الحصص.
الحصة لكل مشروع |
طرق Chat API |
الحدّ الأقصى (لكل 60 ثانية) |
---|---|---|
عدد الرسائل التي تمت كتابتها في الدقيقة |
|
3,000 |
عدد مرّات قراءة الرسائل في الدقيقة |
|
3,000 |
عمليات كتابة العضوية في الدقيقة |
|
300 |
عدد القراءات في الدقيقة |
|
3,000 |
عمليات الكتابة في الفضاء في الدقيقة |
|
60 |
عدد مرّات القراءة في الدقيقة |
|
3,000 |
عدد عمليات الكتابة في المرفق في الدقيقة |
|
600 |
عدد مرات قراءة المرفق في الدقيقة |
|
3,000 |
عدد مرّات كتابة التفاعل في الدقيقة |
|
600 |
عدد مرّات قراءة التفاعل في الدقيقة |
|
3,000 |
الحدود القصوى للاستخدام
هناك حدود إضافية للحصة المخصّصة لإنشاء مساحات من النوع GROUP_CHAT
أو SPACE
(باستخدام طريقة spaces.create
أو spaces.setup
).
أنشئ أقل من 35 مساحة في الدقيقة و210 مساحة في
الساعة من هذه الأنواع. ولا تخضع المساحات من النوع DIRECT_MESSAGE
لحدود الحصص الإضافية هذه.
يمكن أن تؤدي طلبات البحث الكبيرة في الثانية (QPS) لأي واجهة برمجة تطبيقات تستهدف المساحة نفسها إلى تفعيل حدود داخلية إضافية لا تظهر في صفحة الحصص.
حلّ أخطاء الحصص المستندة إلى الوقت
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (بحد أقصى عدد من الطلبات لكل X دقيقة)، ننصحك بأن يلتقط الرمز البرمجي الاستثناء وأن يستخدم خوارزمية رقودة ثنائية مقتطعة للتأكّد من عدم تحمّل الأجهزة حِملًا زائدًا.
يعتبر الرقود الأسي استراتيجية قياسية لمعالجة الأخطاء لتطبيقات الشبكة. يعيد خوارزمية الرقود الأسي إجراء الطلبات باستخدام فترات انتظار متزايدة متزايدة بين الطلبات، وصولاً إلى أقصى حد لوقت التراجع. وإذا لم يتم قبول الطلبات، من المهم أن تتزايد حالات التأخير بين الطلبات بمرور الوقت إلى أن يتم قبولها.
مثال على الخوارزمية
تعيد خوارزمية الرقود الأسي محاولة تكرار الطلبات بشكل كبير، ما يزيد من وقت الانتظار بين عمليات إعادة المحاولة إلى أقصى حد لوقت التراجع. مثال:
- يمكنك تقديم طلب إلى Google Chat API.
- إذا تعذّر إجراء الطلب، انتظر 1 +
random_number_milliseconds
ثم أعِد محاولة الطلب. - وإذا تعذّر إجراء الطلب، انتظِر 2 +
random_number_milliseconds
ثم أعِد محاولة الطلب. - وإذا تعذّر إجراء الطلب، انتظِر لمدة 4 +
random_number_milliseconds
ثم أعِد محاولة الطلب. - وهكذا، حتى مرة واحدة (
maximum_backoff
). - يمكنك مواصلة الانتظار وإعادة المحاولة لتصل إلى الحد الأقصى المسموح به لعدد عمليات إعادة المحاولة، ولكن مع عدم زيادة فترة الانتظار بين عمليات إعادة المحاولة.
المكان:
- يبلغ وقت الانتظار
min(((2^n)+random_number_milliseconds), maximum_backoff)
، مع زيادةn
بمقدار مرة واحدة لكل تكرار (طلب). random_number_milliseconds
هو عدد عشوائي بالمللي ثانية أقل من أو يساوي 1,000. يساعد ذلك في تجنُّب الحالات التي تتم فيها مزامنة العديد من البرامج في حالة معيّنة وإعادة المحاولة جميعها في وقت واحد، مع إرسال الطلبات في موجات متزامنة. يُعاد احتساب قيمةrandom_number_milliseconds
بعد كل طلب لإعادة المحاولة.- وتتراوح مدة
maximum_backoff
عادةً بين 32 أو 64 ثانية. وتعتمد القيمة المناسبة على حالة الاستخدام.
يمكن للعميل مواصلة إعادة المحاولة بعد انتهاء الوقت maximum_backoff
.
لا يلزم إعادة المحاولة بعد هذه المرحلة لزيادة وقت التراجع. على سبيل المثال، إذا كان العميل يستخدم وقت maximum_backoff
مدّته 64 ثانية، يمكن للعميل إعادة المحاولة كل 64 ثانية بعد الوصول إلى هذه القيمة. ومن المفترض أن يُمنع العملاء في مرحلة ما من إعادة المحاولة إلى أجل غير مسمى.
يعتمد وقت الانتظار بين عمليات إعادة المحاولة وعدد هذه المحاولات على حالة الاستخدام وحالة الشبكة.
طلب زيادة في الحصة لكل مشروع
بناءً على استخدام مشروعك للموارد، قد تريد طلب زيادة في الحصة. أما طلبات البيانات من واجهة برمجة التطبيقات التي يجريها حساب خدمة، فيُعتبر أنّ هذه الطلبات تستخدم حسابًا واحدًا. إنّ التقدّم بطلب للحصول على حصة أكبر لا يضمن الموافقة. قد تستغرق زيادات الحصص الكبيرة وقتًا أطول للموافقة عليها.
لا تحتوي جميع المشروعات على الحصص نفسها. مع تزايد استخدام Google Cloud بمرور الوقت، قد تحتاج حصصك إلى زيادة. إذا كنت تتوقّع زيادة ملحوظة في الاستخدام، يمكنك طلب تعديلات على الحصص بشكل استباقي من صفحة الحصص في Google Cloud Console.
لمزيد من المعلومات، اطّلِع على المراجع التالية: