Google Ads API محدودیت نرخ را براساس پُرسمان در ثانیه (QPS) هم برای شناسه‌های مشتری و هم برای پروژه‌های Google Cloud به‌طور مستقل اعمال می‌کند. علاوه‌بر درخواست‌ها در دقیقه (که بسامد فراخوانی‌های میانای برنامه‌سازی کاربردی را می‌سنجد)، Google Ads API محدودیت‌هایی را نیز بر عملیات‌ها در دقیقه (که تعداد کل عملیات‌های میانای برنامه‌سازی کاربردی را در درخواست‌ها می‌سنجد) اعمال می‌کند. Google Ads API از الگوریتم سطل توکن برای اندازه‌گیری درخواست‌ها و تعیین حد مناسب «پرس‌وجو در ثانیه» استفاده می‌کند، بنابراین حد دقیق بسته به بار کلی سرور در هر زمان معین متفاوت است.
هدف از اعمال محدودیت‌های نرخ این است که از اختلال یک کاربر در سرویس برای کاربران دیگر (چه به‌صورت عمدی یا غیرعمدی) با ارسال حجم بالایی از درخواست‌ها به سرورهای Google Ads API جلوگیری شود.
درخواست‌هایی که حد نرخ را نقض می‌کنند با این خطا رد می‌شوند:
RESOURCE_TEMPORARILY_EXHAUSTED.
با کاهش فعال تعداد درخواست‌ها و محدود کردن QPS از سمت مشتری، می‌توانید کنترل برنامه خود را در دست بگیرید و محدودیت‌های نرخ را کاهش دهید.
چندین روش برای کاهش احتمال فراتر رفتن از حد نرخ وجود دارد. آشنایی با مفاهیم الگوهای ادغام سازمانی (EIP) مانند پیام‌رسانی، ارسال مجدد، و محدودسازی می‌تواند به شما کمک کند تا برنامه مشتری قوی‌تری بسازید.
روال‌های توصیه‌شده زیر براساس پیچیدگی مرتب شده‌اند، به‌طوری‌که استراتژی‌های ساده‌تر در بالا و معماری‌های قوی‌تر اما پیچیده‌تر در ادامه قرار دارند:
- عقب‌گرد نمایی
- محدود کردن تکالیف هم‌زمان
- درخواست‌های دسته‌ای
- محدودکننده‌های نرخ و محدود کردن شبکه
- درحال صف‌بندی
عقب‌نشینی نمایی
وقتی برنامه‌تان خطای
RESOURCE_TEMPORARILY_EXHAUSTED دریافت می‌کند، قبل‌از امتحان مجدد درخواست ناموفق، از خط‌مشی
عقب‌نشینی نمایی با لرزش تصادفی استفاده کنید. عقب‌گرد نمایی به‌تدریج زمان انتظار بین تلاش‌های مجدد را افزایش می‌دهد (برای مثال، ۲ ثانیه انتظار، سپس ۴ ثانیه، سپس ۸ ثانیه، به‌علاوه یک تأخیر تصادفی کوچک)، که به بار سرور و سطل‌های سهمیه اجازه می‌دهد بازیابی شوند و درعین‌حال از افزایش ناگهانی تلاش‌های مجدد همگام‌سازی‌شده در نمونه‌های کارخواه جلوگیری می‌کند.
محدود کردن تکالیف هم‌زمان
یکی از دلایل ریشه‌ای فراتر رفتن از حد مجاز بسامد این است که برنامه کارخواه تعداد زیادی تکلیف موازی ایجاد می‌کند. درحالی‌که تعداد درخواست‌های موازی را که برنامه کارخواه می‌تواند داشته باشد محدود نمی‌کنیم، این تعداد می‌تواند از حد مجاز درخواست در ثانیه در سطح پروژه Google Cloud فراتر رود.
تنظیم یک حد بالای معقول برای تعداد کل تکالیف هم‌زمان که درخواست ارسال می‌کنند (در همه فرایندها و ماشین‌ها)، و تنظیم به‌سمت بالا برای بهینه‌سازی توان عملیاتی بدون فراتر رفتن از حد نرخ توصیه می‌شود.
علاوه‌براین، می‌توانید درنظر بگیرید که QPS را از سمت کارخواه محدود کنید (به محدود کردن و محدودکننده‌های نرخ مراجعه کنید).
درخواست‌های دسته‌ای
چندین عملیات را در یک درخواست دسته‌بندی کنید. این مورد بیشتر
برای تماس‌های Mutate برای سرویس‌های مختلف کاربرد دارد. برای مثال، اگر درحال به‌روزرسانی وضعیت برای چند نمونه از AdGroupAd هستید، می‌توانید MutateAdGroupAds را یک‌بار فراخوانی کنید و چند operations را به‌جای یک‌بار فراخوانی MutateAdGroupAds برای هر AdGroupAd ارسال کنید. برای چند نمونه بیشتر، به
راهنمایی‌های عملیات دسته‌ای ما مراجعه کنید.
درحالی‌که دسته‌بندی درخواست‌ها تعداد کل فراخوانی‌های API را کاهش می‌دهد و محدودیت‌های نرخ درخواست‌ها در دقیقه را کاهش می‌دهد، اگر تعداد زیادی عملیات را برای یک حساب انجام دهید، ممکن است محدودیت نرخ عملیات در دقیقه را فعال کند.
محدود کردن شبکه و محدودکننده‌های نرخ
علاوه‌بر محدود کردن تعداد کل رشته‌ها در برنامه‌تان، می‌توانید همچنین محدودکننده‌های نرخ را در سمت مشتری پیاده‌سازی کنید. این کار تضمین می‌کند که همه رشته‌ها در سراسر فرایندها، خوشه‌ها، یا هر دو تحت نظارت محدودیت QPS خاصی ازطرف کارخواه باشند.
Guava RateLimiter را ببینید یا الگوریتم token bucket خودتان را برای محیط خوشه‌ای پیاده‌سازی کنید. برای مثال، می‌توانید توکن‌ها را در یک پایگاه داده درون‌حافظه‌ای توزیع‌شده با تأخیر کم مانند Redis یا Memcached مدیریت کنید، جایی که هر مشتری قبل‌از پردازش درخواست، یک توکن دریافت و مصرف می‌کند. اگر توکن‌ها تمام شوند، کارخواه تا زمانی که دسته بعدی توکن‌ها تأمین شود منتظر می‌ماند.
در صف گذاشتن
صف پیام راه‌حلی برای توزیع بار عملیات است و درعین‌حال نرخ درخواست و مصرف‌کننده را کنترل می‌کند. گزینه‌های متعددی برای صف پیام وجود دارد (برخی متن‌باز و برخی اختصاصی) و بسیاری از آن‌ها می‌توانند با زبان‌های مختلف کار کنند.
هنگام استفاده از صف‌های پیام، می‌توانید چندین تولیدکننده داشته باشید که پیام‌ها را به صف ارسال می‌کنند و چندین مصرف‌کننده که این پیام‌ها را پردازش می‌کنند. می‌توان با محدود کردن تعداد مصرف‌کنندگان هم‌زمان، یا با پیاده‌سازی محدودکننده‌های نرخ یا محدودکننده‌های پهنای باند برای تولیدکنندگان یا مصرف‌کنندگان، محدودیت پهنای باند را در سمت مصرف‌کننده اعمال کرد.
برای مثال، اگر مصرف‌کننده پیام با خطای محدودیت نرخ مواجه شود، آن مصرف‌کننده می‌تواند درخواست را با تأخیر استانداردشده‌ای برای تلاش مجدد (بااستفاده از پس‌رفت نمایی) به صف برگرداند و حلقه بازخورد محدودکننده نرخ مشترک را به‌روز کند تا همه مصرف‌کنندگان به‌طور خودکار نرخ پردازش خود را درحین بازیابی از خطا کاهش دهند.