از آنجا که رابط برنامه‌نویسی کاربردی گوگل چت یک سرویس اشتراکی است، ما سهمیه‌ها و محدودیت‌هایی را اعمال می‌کنیم تا مطمئن شویم که همه کاربران به طور منصفانه از آن استفاده می‌کنند و از عملکرد کلی گوگل ورک‌اسپیس محافظت شود.
اگر از سهمیه تعیین‌شده تجاوز کنید، پاسخ کد وضعیت HTTP با عنوان 429: Too many requests دریافت خواهید کرد. بررسی‌های بیشتر در مورد محدودیت سرعت در بخش مدیریت چت نیز ممکن است همین پاسخ خطا را ایجاد کند. در صورت بروز این خطا، باید از الگوریتم بازگشت نمایی استفاده کنید و بعداً دوباره امتحان کنید. تا زمانی که در محدوده سهمیه‌های دقیقه‌ای ذکر شده در جداول زیر بمانید، هیچ محدودیتی برای تعداد درخواست‌هایی که می‌توانید در روز انجام دهید وجود ندارد.
چندین نوع سهمیه‌بندی می‌تواند برای متدهای Chat API اعمال شود: سهمیه‌بندی به ازای هر پروژه، به ازای هر فضا و به ازای هر کاربر.
سهمیه‌های هر پروژه
سهمیه‌های هر پروژه، نرخ پرس‌وجوها را برای یک پروژه Google Cloud محدود می‌کنند و بنابراین برای یک برنامه چت واحد که متدهای API چت مشخص شده را برای هر سهمیه فراخوانی می‌کند، اعمال می‌شوند.
جدول زیر محدودیت‌های پرس‌وجو برای هر پروژه را نشان می‌دهد. همچنین می‌توانید این محدودیت‌ها را در صفحه سهمیه‌ها (Quotas) پیدا کنید.
سهمیه هر پروژه | متدهای API چت | محدودیت (در هر ۶۰ ثانیه) |
|---|---|---|
نوشتن پیام در دقیقه | | ۳۰۰۰ |
تعداد خوانده شدن پیام در دقیقه | | ۳۰۰۰ |
تعداد نوشته‌های عضویت در هر دقیقه | | ۳۰۰ |
تعداد دفعات بازدید از عضویت در هر دقیقه | | ۳۰۰۰ |
نوشتن فضا در دقیقه | | ۶۰ |
فضا در هر دقیقه خوانده می‌شود | | ۳۰۰۰ |
تعداد نوشتن پیوست در دقیقه | | ۶۰۰ |
تعداد دفعات خواندن پیوست در دقیقه | | ۳۰۰۰ |
تعداد نوشته‌های واکنش در دقیقه | | ۶۰۰ |
تعداد واکنش در دقیقه | | ۳۰۰۰ |
سهمیه هر فضا
سهمیه‌های هر فضا، نرخ پرس‌وجوها را در یک فضای مشخص محدود می‌کنند و بین تمام برنامه‌های چت فعال در آن فضا که متدهای API چت ذکر شده را برای هر سهمیه فراخوانی می‌کنند، به اشتراک گذاشته می‌شوند.
جدول زیر محدودیت‌های پرس‌وجو به ازای هر فاصله را شرح می‌دهد:
سهمیه هر فضا | متدهای API چت | محدودیت (در ثانیه) |
|---|---|---|
تعداد دفعات خواندن در ثانیه | | ۱۵ |
نوشتن در ثانیه | | ۱ |
تعداد دفعات نوشتن در ثانیه در واکنش‌های Create | | ۵ |
تعداد نوشتن پیام در هر ثانیه هنگام وارد کردن داده‌ها به گوگل چت | | ۱۰ |
سهمیه هر کاربر
سهمیه هر کاربر، نرخ پرس‌وجوها را برای یک کاربر Google Chat محدود می‌کند. پرس‌وجوها مربوط به همه برنامه‌های چت هستند که از طرف یک کاربر (با استفاده از احراز هویت کاربر ) یک متد Chat API را فراخوانی می‌کنند.
جدول زیر محدودیت‌های پرس‌وجو برای هر کاربر را نشان می‌دهد:
سهمیه هر کاربر | متدهای API چت | محدودیت (در ثانیه) |
|---|---|---|
تعداد دفعات خواندن در ثانیه | | ۱۵ |
نوشتن در ثانیه | | ۱ |
محدودیت‌های استفاده اضافی
محدودیت‌های سهمیه‌بندی اضافی برای ایجاد فضاهایی از نوع GROUP_CHAT یا SPACE (با استفاده از متد spaces.create یا spaces.setup ) وجود دارد. کمتر از 35 فضا در دقیقه و 800 فضا در ساعت از این نوع‌ها ایجاد کنید. فضاهایی از نوع DIRECT_MESSAGE مشمول این محدودیت‌های سهمیه‌بندی اضافی نمی‌شوند.
ترافیک بالای API که همان فضا را هدف قرار می‌دهد، می‌تواند محدودیت‌های داخلی بیشتری را ایجاد کند که در صفحه سهمیه‌ها قابل مشاهده نیستند.
خطاهای سهمیه‌بندی مبتنی بر زمان را برطرف کنید
برای همه خطاهای مبتنی بر زمان (حداکثر N درخواست در هر X دقیقه)، توصیه می‌کنیم کد شما استثنا را دریافت کند و از یک backoff نمایی کوتاه شده استفاده کند تا مطمئن شود دستگاه‌های شما بار اضافی تولید نمی‌کنند.
بازگشت نمایی یک استراتژی استاندارد مدیریت خطا برای برنامه‌های شبکه است. یک الگوریتم بازگشت نمایی، درخواست‌ها را با استفاده از زمان انتظار بین درخواست‌ها که به صورت نمایی افزایش می‌یابد، تا حداکثر زمان بازگشت، دوباره امتحان می‌کند. اگر درخواست‌ها همچنان ناموفق باشند، مهم است که تأخیر بین درخواست‌ها به مرور زمان افزایش یابد تا درخواست موفقیت‌آمیز شود.
الگوریتم مثال
یک الگوریتم بازگشت نمایی، درخواست‌ها را به صورت نمایی دوباره امتحان می‌کند و زمان انتظار بین تلاش‌های مجدد را تا حداکثر زمان بازگشت افزایش می‌دهد. برای مثال:
- یک درخواست به Google Chat API ارسال کنید.
- اگر درخواست با شکست مواجه شد، ۱ +
random_number_millisecondsصبر کنید و درخواست را دوباره امتحان کنید. - اگر درخواست با شکست مواجه شد، به مدت ۲ +
random_number_millisecondsصبر کنید و درخواست را دوباره امتحان کنید. - اگر درخواست با شکست مواجه شد، به مدت ۴ +
random_number_millisecondsصبر کنید و درخواست را دوباره امتحان کنید. - و به همین ترتیب، تا زمان
maximum_backoff. - تا حداکثر تعداد دفعات تلاش مجدد، به انتظار و تلاش مجدد ادامه دهید، اما مدت زمان انتظار بین تلاش‌ها را افزایش ندهید.
کجا:
- زمان انتظار
min(((2^n)+random_number_milliseconds), maximum_backoff)است، که در آنnبرای هر تکرار (درخواست) 1 واحد افزایش می‌یابد. -
random_number_millisecondsیک عدد تصادفی میلی‌ثانیه کمتر یا مساوی ۱۰۰۰ است. این به جلوگیری از مواردی که بسیاری از کلاینت‌ها به دلیل برخی شرایط همگام‌سازی می‌شوند و همه به طور همزمان تلاش مجدد می‌کنند و درخواست‌ها را در امواج هماهنگ ارسال می‌کنند، کمک می‌کند. مقدارrandom_number_millisecondsپس از هر درخواست تلاش مجدد دوباره محاسبه می‌شود. -
maximum_backoffمعمولاً ۳۲ یا ۶۴ ثانیه است. مقدار مناسب به مورد استفاده بستگی دارد.
کلاینت می‌تواند پس از رسیدن به زمان maximum_backoff به تلاش مجدد ادامه دهد. تلاش‌های مجدد پس از این نقطه نیازی به افزایش مداوم زمان backoff ندارند. برای مثال، اگر یک کلاینت از زمان maximum_backoff برابر با ۶۴ ثانیه استفاده کند، پس از رسیدن به این مقدار، کلاینت می‌تواند هر ۶۴ ثانیه دوباره تلاش کند. در مقطعی، کلاینت‌ها باید از تلاش مجدد نامحدود منع شوند.
زمان انتظار بین تلاش‌های مجدد و تعداد تلاش‌های مجدد به مورد استفاده شما و شرایط شبکه بستگی دارد.
درخواست افزایش سهمیه هر پروژه
بسته به میزان استفاده از منابع پروژه‌تان، ممکن است بخواهید درخواست تنظیم سهمیه بدهید. فراخوانی‌های API توسط یک حساب کاربری سرویس، به عنوان استفاده از یک حساب کاربری واحد در نظر گرفته می‌شوند. درخواست برای سهمیه تنظیم‌شده، تضمینی برای تأیید نیست. درخواست‌های تنظیم سهمیه که مقدار سهمیه را به میزان قابل توجهی افزایش می‌دهند، ممکن است مدت زمان بیشتری طول بکشد تا تأیید شوند.
همه پروژه‌ها سهمیه‌های یکسانی ندارند. با گذشت زمان و افزایش استفاده از گوگل کلود، ممکن است لازم باشد مقادیر سهمیه شما افزایش یابد. اگر انتظار افزایش قابل توجه استفاده در آینده را دارید، می‌توانید به صورت پیشگیرانه از صفحه سهمیه‌ها در کنسول گوگل کلود ، درخواست تنظیم سهمیه کنید .
برای مطالعه بیشتر، به منابع زیر مراجعه کنید:
- درباره تعدیل سهمیه‌ها
- مشاهده میزان استفاده و محدودیت‌های سهمیه فعلی شما
- درخواست محدودیت سهمیه بالاتر