تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تبلغ الحدود القصوى التلقائية لواجهة برمجة التطبيقات Google Play EMM 60,000 طلب بحث في الدقيقة لكل خدمة إدارة خدمات جوّالة للمؤسسات.
إذا تجاوزت الحصة، ستُرجع واجهة برمجة التطبيقات Google Play EMM API القيمة HTTP 429 Too Many Requests.
للمساعدة في ضمان عدم تجاوز حدود الاستخدام المحدّدة وتقديم تجربة مثالية
للمستخدمين، ننصحك بتنفيذ بعض أفضل الممارسات الموضّحة في القسم أدناه.
اقتراحات للبقاء ضمن حدود استخدام واجهة برمجة التطبيقات
عند استخدام واجهة برمجة التطبيقات Google Play EMM API، هناك بعض أفضل الممارسات التي يمكنك تنفيذها لتوزيع الطلبات والحد من خطر تجاوز حدود الاستخدام.
توزيع أوقات البدء والفواصل الزمنية بشكل عشوائي
من المحتمل أن تؤدي أنشطة مثل مزامنة الأجهزة أو تسجيل الوصول إليها في الوقت نفسه إلى
زيادة كبيرة في حجم الطلبات. وبدلاً من تنفيذ هذه الأنشطة على فترات زمنية
مجدولة بشكل منتظم، يمكنك توزيع تحميل طلبك من خلال ترتيب هذه الفواصل بشكل عشوائي. على سبيل المثال،
بدلاً من مزامنة كل جهاز كل 24 ساعة، يمكنك مزامنة كل جهاز خلال فترة زمنية
يتم اختيارها عشوائيًا تتراوح بين 23 و25 ساعة. وهذا يساعد في توزيع عدد الطلبات.
وبالمثل، إذا كنت تدير مهمة يومية تُجري العديد من طلبات البيانات من واجهة برمجة التطبيقات بشكلٍ سريع، ننصحك ببدء المهمة في وقت عشوائي كل يوم لتجنُّب إرسال عدد كبير من الطلبات لجميع عملاء مؤسستك في الوقت نفسه.
استخدام خوارزمية الرقود الأسي الثنائي لإعادة محاولة إرسال الطلبات
إذا كنت تُشغّل مهام تتألف من العديد من طلبات بيانات واجهة برمجة التطبيقات، استخدِم استراتيجية التراجع الدليلي في
الاستجابة للوصول إلى الحصة. خوارزمية الرقود الأسي هي خوارزمية تعيد توجيه الطلبات بشكل كبير. فيما يلي مثال على التدفق لتنفيذ الرقود الأسي البسيط:
أرسِل طلبًا إلى واجهة برمجة التطبيقات Google Play EMM API.
تلقّي ردّ HTTP 429
انتظِر لمدة ثانيتَين + random_time، ثم أعِد محاولة إجراء الطلب.
تلقّي ردّ من "HTTP 429"
انتظِر 4 ثوانٍ + random_time، ثم أعِد محاولة إجراء الطلب.
تلقّي ردّ HTTP 429
يُرجى الانتظار لمدة 8 ثوانٍ + random_time، ثم إعادة محاولة الطلب.
ويكون random_time عادةً رقمًا عشوائيًا يتراوح بين -0.5 * وقت الانتظار
و +0.5 * وقت الانتظار. أعِد تحديد random_time جديد في كل مرة تعيد فيها محاولة
إرسال طلبك. يمكن إعادة محاولة طلبات البيانات من واجهة برمجة التطبيقات المطلوبة لإكمال الإجراءات الموجَّهة للمستخدمين وفقًا لجدول
زمني أكثر تكرارًا (على سبيل المثال، 0.5 ثانية وثانية و2 ثانية).
عمليات المعالجة على دفعات التي تخضع لقيود على معدّل الاستخدام
في كل مرة تصل فيها عملية مجمّعة إلى الحصة، تزداد مدة استجابة إجراءات المستخدمين التي تستدعي واجهة برمجة التطبيقات. في مثل هذه الحالات، قد لا تكون استراتيجيات مثل التراجع المتزايد فعالة
بما يكفي للحفاظ على وقت استجابة منخفض لإجراءات المستخدم.
لتجنّب بلوغ حدود الاستخدام القصوى لواجهة برمجة التطبيقات بشكل متكرّر وزيادة وقت الاستجابة للإجراءات الموجَّهة للمستخدمين، يمكنك استخدام محدِّد لمعدل الزيارات للعمليات المجمّعة (يمكنك الاطّلاع على السعر المحدد من Google).
باستخدام أداة الحدّ من معدّل الإرسال، يمكنك تعديل معدّل طلبات واجهة برمجة التطبيقات بحيث تظلّ باستمرار
ضمن حدود الاستخدام.
على سبيل المثال، ابدأ عملية مجمّعة بحدّ أقصى تلقائي للمعدل يبلغ 50 طلب في الثانية. طالما أنّ واجهة برمجة التطبيقات
لا تعرِض خطأ، يمكنك زيادة الحدّ الأقصى للمعدل ببطء (1% كل دقيقة). في كل مرة تصل فيها
إلى الحصة، عليك خفض معدّل الطلبات بنسبة %20. يؤدّي هذا النهج التكيُّفي إلى تحقيق معدل إرسال طلبات مثالي بشكل أكبر مع تقليل وقت الاستجابة للإجراءات الموجَّهة للمستخدمين.
تاريخ التعديل الأخير: 2024-11-09 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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"]],["تاريخ التعديل الأخير: 2024-11-09 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eThe Google Play EMM API has a default limit of 60,000 queries per minute per EMM, exceeding which results in an HTTP 429 Too Many Requests error.\u003c/p\u003e\n"],["\u003cp\u003eTo avoid exceeding the usage limit, randomize device sync intervals and job start times to distribute the request load.\u003c/p\u003e\n"],["\u003cp\u003eImplement exponential backoff to retry requests with increasing wait times after receiving HTTP 429 errors.\u003c/p\u003e\n"],["\u003cp\u003eFor batch processes, utilize a rate limiter to adjust the request rate dynamically and prevent consistently hitting the usage limit, ensuring low latency for user actions.\u003c/p\u003e\n"]]],[],null,["# Usage Limits\n\nThe Google Play EMM API has a default limit of 60,000 queries per minute for each EMM.\n\nIf you exceed the quota, then the Google Play EMM API returns `HTTP 429 Too Many Requests`.\nTo help ensure that you don't exceed the stated usage limits and offer an optimal experience for\nyour users, consider implementing some of the best practices described in the section below.\n\nRecommendations for staying below the API usage limits\n------------------------------------------------------\n\nWhen using the Google Play EMM API, there are some best practices that you can implement to\ndistribute requests and reduce your risk of exceeding the usage limits.\n\n### Randomize start times and intervals\n\nActivities such as syncing or checking-in devices at the same time are likely to result in a\nsignificant increase in request volume. Instead of performing these activities at regularly\nscheduled intervals, you can distribute your request load by randomizing these intervals. For\nexample, rather than syncing each device every 24 hours, you can sync each device at a randomly\nchosen time period between 23 and 25 hours. This helps spread out the number of requests.\n\nSimilarly, if you run a daily job that makes many API calls in quick succession, consider\nstarting the job at a random time each day to prevent making a high volume of requests for all\nyour enterprise customers at the same time.\n\n### Use exponential backoff to retry requests\n\nIf you run jobs that consists of many API calls, use an exponential backoff strategy in\nresponse to reaching the quota. Exponential backoff is an algorithm that retries requests\nexponentially. An example flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the Google Play EMM API.\n2. Receive an `HTTP 429` response.\n3. Wait 2 seconds + `random_time`, then retry the request.\n4. Receive an `HTTP 429` response.\n5. Wait 4 seconds + `random_time`, then retry the request.\n6. Receive an `HTTP 429` response.\n7. Wait 8 seconds + `random_time`, then retry the request.\n\nThe `random_time` is typically a random number ranging from ***-0.5 \\* wait time***\nto ***+0.5 \\* wait time*** . Redefine a new `random_time` each time you retry your\nrequest. API calls that are required to complete user-facing actions can be retried on a more\nfrequent schedule (0.5s, 1s, and 2s, for example).\n\n### Rate-limit batch processes\n\nEach time a batched process reaches the quota, the latency of user actions that call the API\nincreases. In situations like these, strategies such as exponential backoff may not be effective\nenough in maintaining low latency for user actions.\n\nTo avoid reaching the API's usage limits repeatedly and increasing latency for user-facing\nactions, consider using a rate limiter for your batched processes (see [Google's RateLimiter](https://google.github.io/guava/releases/19.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html)).\nWith a rate limiter you can adjust the rate of your API requests so that you consistently remain\nbelow the usage limits.\n\nFor example, start a batched process with a default rate limit of 50 QPS. As long as the API\ndoesn't return an error, increase the rate limit slowly (1% every minute). Each time you reach\nthe quota, reduce your request rate by 20%. This adaptive approach results in a more optimal\nrequest rate while reducing latency for user-facing actions."]]
