با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
از آنجایی که Google Slides API یک سرویس مشترک است، برای اطمینان از استفاده منصفانه توسط همه کاربران و محافظت از سلامت کلی سیستم Google Workspace، سهمیه‌ها و محدودیت‌هایی اعمال می‌کنیم.
اگر از حد مجاز فراتر رفتید، معمولاً یک پاسخ کد وضعیت HTTP 429: Too many requests دریافت خواهید کرد. اگر این اتفاق افتاد، باید از الگوریتم عقب‌نشینی نمایی استفاده کنید و بعداً دوباره امتحان کنید. به شرطی که در سهمیه‌های هر دقیقه زیر بمانید، محدودیتی برای تعداد درخواست‌هایی که می‌توانید در روز انجام دهید وجود ندارد.
جدول زیر محدودیت های درخواست را شرح می دهد:
سهمیه ها
درخواست ها را بخوانید
در هر دقیقه در هر پروژه
3000
در هر دقیقه برای هر کاربر در هر پروژه
600
درخواست های خواندنی گران قیمت
(برای درخواست های presentations.pages.getThumbnail استفاده می شود.)
در هر دقیقه در هر پروژه
300
در هر دقیقه برای هر کاربر در هر پروژه
60
درخواست ها را بنویسید
در هر دقیقه در هر پروژه
600
در هر دقیقه برای هر کاربر در هر پروژه
60
خطاهای سهمیه بندی مبتنی بر زمان را برطرف کنید
برای همه خطاهای مبتنی بر زمان (حداکثر N درخواست در هر X دقیقه)، توصیه می‌کنیم کد شما استثنا باشد و از یک عقب‌نشینی نمایی کوتاه‌شده استفاده کند تا مطمئن شود دستگاه‌های شما بار بیش از حد تولید نمی‌کنند.
عقب نشینی نمایی یک استراتژی مدیریت خطای استاندارد برای برنامه های شبکه است. یک الگوریتم عقب‌نشینی نمایی، درخواست‌ها را با استفاده از افزایش تصاعدی زمان انتظار بین درخواست‌ها، تا حداکثر زمان عقب‌نشینی، دوباره امتحان می‌کند. اگر درخواست‌ها همچنان ناموفق هستند، مهم است که تأخیر بین درخواست‌ها در طول زمان افزایش یابد تا درخواست موفقیت‌آمیز شود.
الگوریتم نمونه
یک الگوریتم عقب‌نشینی نمایی، درخواست‌ها را به‌صورت تصاعدی دوباره امتحان می‌کند، و زمان انتظار بین تلاش‌های مجدد را تا حداکثر زمان عقب‌نشینی افزایش می‌دهد. به عنوان مثال:
درخواستی را به Google Slides API ارسال کنید.
اگر درخواست ناموفق بود، 1 + random_number_milliseconds صبر کنید و درخواست را دوباره امتحان کنید.
اگر درخواست ناموفق بود، 2 + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
اگر درخواست ناموفق بود، 4 + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
و به همین ترتیب، تا maximum_backoff زمان بازگشت.
به انتظار و تلاش مجدد تا حداکثر تعداد دفعات مجدد ادامه دهید، اما دوره انتظار بین تلاش های مجدد را افزایش ندهید.
کجا:
زمان انتظار 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 ثانیه یکبار دوباره امتحان کند. در برخی موارد، مشتریان باید از تلاش مجدد به طور نامحدود جلوگیری شوند.
زمان انتظار بین تلاش های مجدد و تعداد دفعات مجدد بستگی به حالت استفاده و شرایط شبکه شما دارد.
قیمت گذاری
تمام استفاده از Google Slides API بدون هزینه اضافی در دسترس است. فراتر از محدودیت های درخواست سهمیه هزینه اضافی ندارد و حساب شما صورتحساب نمی شود.
درخواست افزایش سهمیه
بسته به میزان استفاده از منابع پروژه شما، ممکن است بخواهید درخواست افزایش سهمیه کنید. تماس‌های API توسط یک حساب سرویس به عنوان استفاده از یک حساب واحد در نظر گرفته می‌شود. درخواست برای افزایش سهمیه تضمینی برای تایید نیست. افزایش سهمیه های بزرگ ممکن است مدت بیشتری طول بکشد تا تصویب شود.
همه پروژه ها سهمیه یکسانی ندارند. از آنجایی که در طول زمان به طور فزاینده ای از Google Cloud استفاده می کنید، ممکن است نیاز باشد که سهمیه های شما افزایش یابد. اگر انتظار افزایش چشمگیر استفاده در آینده را دارید، می‌توانید به طور فعالانه از صفحه سهمیه‌ها در کنسول Google Cloud درخواست تنظیمات سهمیه کنید .
تاریخ آخرین بهروزرسانی 2025-03-21 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-03-21 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Usage limits\n\nAs the Google Slides API is a shared service, we apply quotas and limitations\nto make sure it's used fairly by all users and to protect the overall\nhealth of the Google Workspace system.\n\n\nIf you exceed a quota, you'll generally receive a\n`429: Too many requests`\nHTTP status code response. If this happens, you should use an\n[exponential backoff algorithm](#exponential) and try again\nlater. Provided you stay within the per-minute quotas below, there's no\nlimit to the number of requests you can make per day.\n\nThe following table details the request limits:\n\n| Quotas ||\n|---------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------|\n| Read requests | |---------------------------------|------| | Per minute per project | 3000 | | Per minute per user per project | 600 | |\n| Expensive read requests (Used for `presentations.pages.getThumbnail` requests.) | |---------------------------------|-----| | Per minute per project | 300 | | Per minute per user per project | 60 | |\n| Write requests | |---------------------------------|-----| | Per minute per project | 600 | | Per minute per user per project | 60 | |\n\nResolve time-based quota errors\n-------------------------------\n\n\nFor all time-based errors (maximum of N requests per X minutes), we recommend\nyour code catches the exception and uses a *truncated exponential backoff* to make sure your\ndevices don't generate excessive load.\n\n\nExponential backoff is a standard error handling strategy for network applications. An\nexponential backoff algorithm retries requests using exponentially increasing wait times\nbetween requests, up to a maximum backoff time. If requests are still unsuccessful, it's\nimportant that the delays between requests increase over time until the request is successful.\n\n### Example algorithm\n\n\nAn exponential backoff algorithm retries requests exponentially, increasing the wait time\nbetween retries up to a maximum backoff time. For example:\n\n1. Make a request to Google Slides API.\n2. If the request fails, wait 1 + `random_number_milliseconds` and retry the request.\n3. If the request fails, wait 2 + `random_number_milliseconds` and retry the request.\n4. If the request fails, wait 4 + `random_number_milliseconds` and retry the request.\n5. And so on, up to a `maximum_backoff` time.\n6. Continue waiting and retrying up to some maximum number of retries, but don't increase the wait period between retries.\n\n\nwhere:\n\n- The wait time is `min(((2^n)+random_number_milliseconds), maximum_backoff)`, with `n` incremented by 1 for each iteration (request).\n- `random_number_milliseconds` is a random number of milliseconds less than or equal to 1,000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of `random_number_milliseconds` is recalculated after each retry request.\n- `maximum_backoff` is typically 32 or 64 seconds. The appropriate value depends on the use case.\n\n\nThe client can continue retrying after it has reached the `maximum_backoff` time.\nRetries after this point don't need to continue increasing backoff time. For\nexample, if a client uses a `maximum_backoff` time of 64 seconds, then after reaching\nthis value, the client can retry every 64 seconds. At some point,\nclients should be prevented from retrying indefinitely.\n\n\nThe wait time between retries and the number of retries depend on your use case\nand network conditions.\n\nPricing\n-------\n\n\nAll use of the Google Slides API is available at no additional cost. Exceeding the quota\nrequest limits doesn't incur extra charges and your account is not billed.\n\nRequest a quota increase\n------------------------\n\n\nDepending on your project's resource usage, you might want to request a quota\nadjustment. API calls by a service account are considered to be using a\nsingle account. Applying for an adjusted quota doesn't guarantee approval. Quota adjustment\nrequests that would significantly increase the quota value can take longer to be approved.\n\n\nNot all projects have the same quotas. As you increasingly use Google Cloud over\ntime, your quota values might need to increase. If you expect a notable upcoming\nincrease in usage, you can proactively\n[request quota adjustments](https://cloud.google.com/docs/quota#requesting_higher_quota)\nfrom the [Quotas page](https://console.cloud.google.com/iam-admin/quotas)\nin the Google Cloud console.\n\nTo learn more, see the following resources:\n\n- [About quota adjustments](https://cloud.google.com/docs/quotas/overview#about_increase_requests)\n- [View your current quota usage and limits](https://cloud.google.com/docs/quota#viewing_your_quota_console)\n- [Request a higher quota limit](https://cloud.google.com/docs/quota#requesting_higher_quota)"]]
