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

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

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

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

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

جدول زیر محدودیت‌های کوئری به ازای هر پروژه را نشان می‌دهد. همچنین می‌توانید این محدودیت‌ها را در صفحه Quotas در کنسول Google Cloud پیدا کنید.

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

متدهای API رویدادهای فضای کاری گوگل

حد

تعداد نوشتن در دقیقه

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

۶۰۰

تعداد نوشتن در دقیقه برای هر کاربر

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

۱۰۰

تعداد دفعات مطالعه در دقیقه

Subscriptions.get

Subscriptions.list

۶۰۰

تعداد دفعات مطالعه در هر دقیقه برای هر کاربر

Subscriptions.get

Subscriptions.list

۱۰۰

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

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

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

الگوریتم مثال

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

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

کجا:

  • زمان انتظار min(((2^n)+random_number_milliseconds), maximum_backoff) است، که در آن n برای هر تکرار (درخواست) 1 واحد افزایش می‌یابد.
  • random_number_milliseconds یک عدد تصادفی میلی‌ثانیه کمتر یا مساوی ۱۰۰۰ است. این به جلوگیری از مواردی که بسیاری از کلاینت‌ها به دلیل برخی شرایط همگام‌سازی می‌شوند و همه به طور همزمان تلاش مجدد می‌کنند و درخواست‌ها را در امواج هماهنگ ارسال می‌کنند، کمک می‌کند. مقدار random_number_milliseconds پس از هر درخواست تلاش مجدد دوباره محاسبه می‌شود.
  • maximum_backoff معمولاً ۳۲ یا ۶۴ ثانیه است. مقدار مناسب به مورد استفاده بستگی دارد.

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

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

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

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

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

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