Google Play EMM API دارای محدودیت پیش‌فرض 60000 درخواست در دقیقه برای هر EMM است.
اگر از سهمیه فراتر رفتید، API EMM Google Play HTTP 429 Too Many Requests برمی‌گرداند. برای اطمینان از اینکه از محدودیت‌های استفاده اعلام‌شده تجاوز نمی‌کنید و تجربه بهینه‌ای را برای کاربران خود ارائه می‌کنید، برخی از بهترین شیوه‌های شرح داده شده در بخش زیر را در نظر بگیرید.
توصیه هایی برای ماندن در زیر محدودیت های استفاده API
هنگام استفاده از Google Play EMM API، بهترین روش‌ها وجود دارد که می‌توانید برای توزیع درخواست‌ها و کاهش خطر فراتر رفتن از محدودیت‌های استفاده، پیاده‌سازی کنید.
زمان ها و فواصل شروع را تصادفی کنید
فعالیت‌هایی مانند همگام‌سازی یا چک کردن دستگاه‌ها به طور همزمان احتمالاً منجر به افزایش قابل توجهی در حجم درخواست می‌شود. به جای انجام این فعالیت ها در بازه های زمانی منظم، می توانید بار درخواست خود را با تصادفی سازی این فواصل توزیع کنید. به عنوان مثال، به جای همگام سازی هر 24 ساعت هر دستگاه، می توانید هر دستگاه را در بازه زمانی انتخابی تصادفی بین 23 تا 25 ساعت همگام سازی کنید. این به گسترش تعداد درخواست ها کمک می کند.
به طور مشابه، اگر یک کار روزانه را اجرا می‌کنید که بسیاری از تماس‌های API را پشت سر هم انجام می‌دهد، کار را در یک زمان تصادفی هر روز شروع کنید تا از ایجاد حجم بالایی از درخواست‌ها برای همه مشتریان سازمانی خود به طور همزمان جلوگیری کنید.
برای امتحان مجدد درخواست ها از عقب نشینی نمایی استفاده کنید
اگر کارهایی را اجرا می‌کنید که شامل بسیاری از تماس‌های API است، در پاسخ به رسیدن به سهمیه، از استراتژی عقب‌نشینی نمایی استفاده کنید. عقب نشینی نمایی الگوریتمی است که درخواست ها را به صورت نمایی دوباره امتحان می کند. یک جریان مثال برای اجرای پس‌آف نمایی ساده به شرح زیر است:
- درخواستی را به Google Play EMM API ارسال کنید.
- پاسخ
HTTP 429را دریافت کنید. - 2 ثانیه +
random_timeصبر کنید، سپس درخواست را دوباره امتحان کنید. - پاسخ
HTTP 429را دریافت کنید. - 4 ثانیه +
random_timeصبر کنید، سپس درخواست را دوباره امتحان کنید. - پاسخ
HTTP 429را دریافت کنید. - ۸ ثانیه +
random_timeصبر کنید، سپس درخواست را دوباره امتحان کنید.
random_time معمولاً یک عدد تصادفی است که از -0.5 * زمان انتظار تا +0.5 * زمان انتظار متغیر است. هر بار که درخواست خود را دوباره امتحان می کنید، یک random_time جدید را دوباره تعریف کنید. تماس‌های API که برای تکمیل اقدامات رو به رو کاربر مورد نیاز هستند، می‌توانند در زمان‌بندی مکررتری دوباره امتحان شوند (مثلاً 0.5 ثانیه، 1 و 2 ثانیه).
فرآیندهای دسته ای نرخ-محدود
هر بار که یک فرآیند دسته‌ای به سهمیه می‌رسد، تأخیر اقدامات کاربر که API را فراخوانی می‌کنند افزایش می‌یابد. در شرایطی مانند این، استراتژی هایی مانند عقب نشینی نمایی ممکن است به اندازه کافی در حفظ تأخیر کم برای اقدامات کاربر مؤثر نباشد.
برای جلوگیری از رسیدن مکرر به محدودیت‌های استفاده API و افزایش تأخیر برای عملکردهای کاربر، استفاده از یک محدودکننده نرخ برای فرآیندهای دسته‌ای خود را در نظر بگیرید (به RateLimiter Google مراجعه کنید). با یک محدود کننده نرخ می توانید نرخ درخواست های API خود را طوری تنظیم کنید که به طور مداوم زیر محدودیت های استفاده باقی بمانید.
برای مثال، یک فرآیند دسته‌ای را با محدودیت نرخ پیش‌فرض 50 QPS شروع کنید. تا زمانی که API خطایی را برنگرداند، محدودیت نرخ را به آرامی افزایش دهید (هر دقیقه 1٪). هر بار که به سهمیه رسیدید، نرخ درخواست خود را 20٪ کاهش دهید. این رویکرد تطبیقی منجر به نرخ درخواست بهینه‌تر می‌شود و در عین حال تأخیر برای اقدامات رو به رو کاربر را کاهش می‌دهد.