محدودیت های استفاده

از آنجایی که Google Chat API یک سرویس مشترک است، برای اطمینان از اینکه همه کاربران به طور منصفانه از آن استفاده می کنند و برای محافظت از عملکرد کلی Google Workspace، سهمیه ها و محدودیت هایی اعمال می کنیم.

اگر از یک سهمیه فراتر رفتید، پاسخ کد وضعیت HTTP 429: Too many requests دریافت خواهید کرد. بررسی‌های محدودیت نرخ اضافی در باطن گپ نیز ممکن است همان پاسخ خطا را ایجاد کند. اگر این خطا رخ داد، باید از الگوریتم عقب‌نشینی نمایی استفاده کنید و بعداً دوباره امتحان کنید. تا زمانی که در سهمیه‌های دقیقه‌ای ذکر شده در جداول زیر بمانید، محدودیتی برای تعداد درخواست‌هایی که می‌توانید در روز انجام دهید وجود ندارد.

دو نوع سهمیه برای روش‌های Chat API اعمال می‌شود: سهمیه‌های هر فضا و هر پروژه.

سهمیه های هر فضا

سهمیه‌های هر فضا، نرخ درخواست‌ها را در یک فضای معین محدود می‌کند و بین همه برنامه‌های گپ فعال در آن فضا به اشتراک گذاشته می‌شود که روش‌های فهرست‌شده Chat API را برای هر سهمیه فراخوانی می‌کنند.

جدول زیر محدودیت های پرس و جو در هر فضا را شرح می دهد:

سهمیه هر فضا	روش های چت API	محدودیت (در هر 60 ثانیه، به اشتراک گذاشته شده است در میان همه برنامه های چت موجود در فضا)
در دقیقه می خواند	media.download spaces.get spaces.members.get spaces.members.list spaces.messages.get spaces.messages.list spaces.messages.attachments.get spaces.messages.reactions.list	900
در دقیقه می نویسد	media.upload spaces.delete spaces.patch spaces.messages.create (برای وب هوک های ورودی نیز کاربرد دارد) spaces.messages.delete spaces.messages.patch spaces.messages.reactions.create spaces.messages.reactions.delete	60

سهمیه های هر پروژه

سهمیه‌های هر پروژه، نرخ درخواست‌ها را برای یک پروژه Google Cloud محدود می‌کند، و بنابراین برای یک برنامه Chat که روش‌های Chat API مشخص‌شده را برای هر سهمیه فراخوانی می‌کند، اعمال می‌شود.

جدول زیر محدودیت های پرس و جوی هر پروژه را شرح می دهد. همچنین می توانید این محدودیت ها را در صفحه سهمیه ها بیابید.

سهمیه هر پروژه	روش های چت API	محدودیت (در هر 60 ثانیه)
پیام در دقیقه می نویسد	spaces.messages.create spaces.messages.patch spaces.messages.delete	3000
خواندن پیام در دقیقه	spaces.messages.get spaces.messages.list	3000
عضویت در دقیقه می نویسد	spaces.members.create spaces.members.delete	300
خواندن عضویت در دقیقه	spaces.members.get spaces.members.list	3000
فضا در دقیقه می نویسد	spaces.setup spaces.create spaces.patch spaces.delete	60
خواندن فضا در دقیقه	spaces.get spaces.list spaces.findDirectMessage	3000
پیوست در دقیقه می نویسد	media.upload	600
پیوست در دقیقه خوانده می شود	spaces.messages.attachments.get media.download	3000
واکنش در دقیقه می نویسد	spaces.messages.reactions.create spaces.messages.reactions.delete	600
واکنش در دقیقه خوانده می شود	spaces.messages.reactions.list	3000

محدودیت های استفاده اضافی

محدودیت‌های سهمیه اضافی برای ایجاد فضاهایی از نوع GROUP_CHAT یا SPACE (با استفاده از روش spaces.create یا spaces.setup ) وجود دارد. کمتر از 35 فاصله در دقیقه و 800 فاصله در ساعت از این نوع ایجاد کنید. فضاهای نوع DIRECT_MESSAGE مشمول این محدودیت‌های سهمیه اضافی نیستند.

ترافیک بالای API با هدف قرار دادن یک فضا می‌تواند محدودیت‌های داخلی اضافی را ایجاد کند که در صفحه سهمیه‌ها قابل مشاهده نیستند.

خطاهای سهمیه بندی مبتنی بر زمان را برطرف کنید

برای همه خطاهای مبتنی بر زمان (حداکثر N درخواست در هر X دقیقه)، توصیه می‌کنیم کد شما استثنا باشد و از یک عقب‌نشینی نمایی کوتاه‌شده استفاده کند تا مطمئن شود دستگاه‌های شما بار بیش از حد تولید نمی‌کنند.

عقب نشینی نمایی یک استراتژی مدیریت خطای استاندارد برای برنامه های شبکه است. یک الگوریتم عقب‌نشینی نمایی، درخواست‌ها را با استفاده از افزایش تصاعدی زمان انتظار بین درخواست‌ها، تا حداکثر زمان عقب‌نشینی، دوباره امتحان می‌کند. اگر درخواست‌ها همچنان ناموفق هستند، مهم است که تأخیر بین درخواست‌ها در طول زمان افزایش یابد تا درخواست موفقیت‌آمیز شود.

الگوریتم نمونه

یک الگوریتم عقب‌نشینی نمایی، درخواست‌ها را به‌صورت تصاعدی دوباره امتحان می‌کند، و زمان انتظار بین تلاش‌های مجدد را تا حداکثر زمان عقب‌نشینی افزایش می‌دهد. به عنوان مثال:

1. از Google Chat API درخواست کنید.
2. اگر درخواست ناموفق بود، 1 + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
3. اگر درخواست ناموفق بود، 2 + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
4. اگر درخواست ناموفق بود، 4 + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
5. و به همین ترتیب، تا maximum_backoff .
6. به انتظار و تلاش مجدد تا حداکثر تعداد دفعات مجدد ادامه دهید، اما دوره انتظار بین تلاش های مجدد را افزایش ندهید.

کجا:

• زمان انتظار min(((2^n)+random_number_milliseconds), maximum_backoff) است، که n برای هر تکرار (درخواست) 1 افزایش می یابد.
• random_number_milliseconds تعداد تصادفی میلی ثانیه کمتر یا مساوی 1000 است. این به جلوگیری از مواردی کمک می کند که در آن بسیاری از مشتریان با برخی موقعیت ها همگام می شوند و همه یکباره دوباره تلاش می کنند و درخواست ها را در امواج همگام ارسال می کنند. مقدار random_number_milliseconds پس از هر درخواست مجدد محاسبه می شود.
• maximum_backoff معمولاً 32 یا 64 ثانیه است. مقدار مناسب بستگی به مورد استفاده دارد.

مشتری می تواند پس از رسیدن به maximum_backoff زمان بازگشت مجدد به تلاش مجدد ادامه دهد. تلاش مجدد بعد از این مرحله نیازی به افزایش زمان عقب نشینی ندارد. به عنوان مثال، اگر یک کلاینت از maximum_backoff 64 ثانیه استفاده کند، پس از رسیدن به این مقدار، مشتری می تواند هر 64 ثانیه یکبار دوباره امتحان کند. در برخی موارد، مشتریان باید از تلاش مجدد به طور نامحدود جلوگیری شوند.

زمان انتظار بین تلاش های مجدد و تعداد دفعات مجدد بستگی به حالت استفاده و شرایط شبکه شما دارد.

درخواست افزایش سهمیه هر پروژه

بسته به میزان استفاده از منابع پروژه شما، ممکن است بخواهید درخواست افزایش سهمیه کنید. تماس‌های API توسط یک حساب سرویس به عنوان استفاده از یک حساب واحد در نظر گرفته می‌شود. درخواست برای افزایش سهمیه تضمینی برای تایید نیست. افزایش سهمیه های بزرگ ممکن است مدت بیشتری طول بکشد تا تصویب شود.

همه پروژه ها سهمیه یکسانی ندارند. از آنجایی که در طول زمان به طور فزاینده ای از Google Cloud استفاده می کنید، ممکن است نیاز باشد که سهمیه های شما افزایش یابد. اگر انتظار افزایش چشمگیر استفاده در آینده را دارید، می‌توانید به طور فعالانه از صفحه سهمیه‌ها در کنسول Google Cloud درخواست تنظیمات سهمیه کنید .

برای کسب اطلاعات بیشتر به منابع زیر مراجعه کنید:

• درباره درخواست های افزایش سهمیه
• میزان استفاده و محدودیت های فعلی خود را مشاهده کنید
• درخواست محدودیت سهمیه بالاتر