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 فراتر رود.
توصیه می‌شود حد بالای معقولی برای تعداد کل تکالیف همزمان که قرار است درخواست ایجاد کنند (در همه فرایندها و دستگاه‌ها) تنظیم کنید و برای بهینه‌سازی توان عملیاتی بدون فراتر رفتن از حد نرخ، آن را افزایش دهید.
علاوه‌براین، می‌توانید «پرس‌وجو در ثانیه» را از سمت کارخواه محدود کنید (به محدودکننده‌های نرخ و محدودسازی مراجعه کنید).
درخواست‌های دسته‌ای
چندین عملیات را در یک درخواست دسته‌بندی کنید. این مورد بیشتر
برای تماس‌های Mutate برای سرویس‌های مختلف کاربرد دارد. برای مثال، اگر درحال به‌روزرسانی وضعیت برای چند نمونه از AdGroupAd هستید، می‌توانید MutateAdGroupAds را یک‌بار فراخوانی کنید و چند operations را به‌جای یک‌بار فراخوانی MutateAdGroupAds برای هر AdGroupAd ارسال کنید. برای چند نمونه دیگر، به
راهنمای عملیات دسته‌ای ما مراجعه کنید.
درحالی‌که دسته‌بندی درخواست‌ها تعداد کل فراخوانی‌های API را کاهش می‌دهد و محدودیت‌های نرخ درخواست‌ها در دقیقه را کاهش می‌دهد، اگر تعداد زیادی عملیات را در یک حساب انجام دهید، ممکن است محدودیت نرخ عملیات در دقیقه را فعال کند.
محدودکننده‌های نرخ و محدود کردن شبکه
علاوه‌بر محدود کردن تعداد کل رشته‌ها در برنامه‌تان، می‌توانید محدودکننده‌های نرخ را نیز در سمت کارخواه پیاده‌سازی کنید. این کار تضمین می‌کند که همه رشته‌ها در سراسر فرایندها، خوشه‌ها، یا هر دو تحت کنترل محدودیت QPS خاصی ازطرف کارخواه باشند.
Guava RateLimiter را ببینید یا الگوریتم سطل توکن خودتان را برای محیط خوشه‌ای پیاده‌سازی کنید. برای مثال، می‌توانید کدها را در یک پایگاه داده درون‌حافظه‌ای توزیع‌شده با تأخیر کم مانند Redis یا Memcached مدیریت کنید، جایی که هر مشتری قبل‌از پردازش درخواست، یک کد را دریافت و مصرف می‌کند. اگر توکن‌ها تمام شوند، کارخواه تا زمانی که دسته بعدی توکن‌ها تأمین شود منتظر می‌ماند.
در صف گذاشتن
صف پیام راه‌حلی برای توزیع بار عملیات است و درعین‌حال نرخ درخواست و مصرف‌کننده را کنترل می‌کند. گزینه‌های متعددی برای صف پیام وجود دارد—برخی متن‌باز و برخی اختصاصی—و بسیاری از آن‌ها می‌توانند با زبان‌های مختلف کار کنند.
هنگام استفاده از صف‌های پیام، می‌توانید چندین تولیدکننده داشته باشید که پیام‌ها را به صف ارسال می‌کنند و چندین مصرف‌کننده که آن پیام‌ها را پردازش می‌کنند. تنظیم‌کننده‌های سرعت را می‌توان در سمت مصرف‌کننده با محدود کردن تعداد مصرف‌کنندگان همزمان، یا با پیاده‌سازی محدودکننده‌های نرخ یا تنظیم‌کننده‌های سرعت برای تولیدکنندگان یا مصرف‌کنندگان اجرا کرد.
برای مثال، اگر مصرف‌کننده پیام با خطای محدودیت نرخ مواجه شود، آن مصرف‌کننده می‌تواند درخواست را با تأخیر استانداردشده در تلاش مجدد (بااستفاده از عقب‌نشینی نمایی) به صف برگرداند و حلقه بازخورد محدودکننده نرخ مشترک را به‌روز کند تا همه مصرف‌کنندگان به‌طور خودکار نرخ پردازش خود را هنگام بازیابی از خطا کاهش دهند.