يبلغ حدّ واجهة برمجة تطبيقات "إدارة الخدمات الجوّالة للمؤسسات" (EMM) في Google Play حدًّا تلقائيًا يبلغ 60,000 طلب بحث في الدقيقة لكل "إدارة الخدمات الجوّالة للمؤسسات".
وإذا تجاوزت الحصة المحددة، ستعرض واجهة برمجة تطبيقات "إدارة الخدمات الجوّالة للمؤسسات" (EMM) في Google Play HTTP 429 Too Many Requests.
للمساعدة في ضمان عدم تجاوز حدود الاستخدام المذكورة وتقديم تجربة مثالية
للمستخدمين، يمكنك تطبيق بعض أفضل الممارسات الموضحة في القسم أدناه.
اقتراحات للبقاء دون حدود استخدام واجهة برمجة التطبيقات
عند استخدام واجهة برمجة تطبيقات "إدارة الخدمات الجوّالة للمؤسسات" (EMM) في Google Play، تتوفّر بعض أفضل الممارسات التي يمكنك تنفيذها لتوزيع الطلبات والحد من خطر تجاوز حدود الاستخدام.
ترتيب أوقات البدء والفواصل عشوائيًا
من المحتمل أن تؤدي أنشطة مثل مزامنة الأجهزة أو تسجيل الوصول إليها في الوقت نفسه إلى زيادة كبيرة في حجم الطلبات. بدلاً من تنفيذ هذه الأنشطة على فترات زمنية مجدولة بشكل منتظم، يمكنك توزيع تحميل الطلبات من خلال التوزيع العشوائي لهذه الفواصل الزمنية. على سبيل المثال، بدلاً من مزامنة كل جهاز كل 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 ثانية و1 ثانية و2 ثانية).
العمليات المجمّعة للحدّ الأقصى لمعدّل الزحف
وفي كل مرة تصل فيها عملية مجمّعة إلى الحصة، يزداد وقت استجابة إجراءات المستخدم التي تستدعي واجهة برمجة التطبيقات. وفي مثل هذه الحالات، قد لا تكون بعض الاستراتيجيات، مثل التنسيق الأسي فعّالة بما يكفي للحفاظ على وقت استجابة سريع لإجراءات المستخدمين.
لتجنّب الوصول إلى حدود استخدام واجهة برمجة التطبيقات بشكل متكرر وزيادة وقت الاستجابة للإجراءات التي يواجهها المستخدم، ننصحك باستخدام أداة تحديد معدّل المعالجة للعمليات المجمّعة (راجِع أداة RateRate من Google). من خلال استخدام معدّل محدّد، يمكنك تعديل معدّل طلبات البيانات من واجهة برمجة التطبيقات (API) بحيث تبقى دون حدود الاستخدام على الدوام.
على سبيل المثال، يمكنك بدء عملية معالجة مجمَّعة بحد أقصى تلقائي للمعدّل يبلغ 50 لقطة في الثانية. وإذا لم تعرض واجهة برمجة التطبيقات أي خطأ، يجب زيادة حدّ المعدل ببطء (1% كل دقيقة). وفي كل مرة تبلغ فيها الحصة المطلوبة، يمكنك تقليل معدّل الطلب بنسبة 20%. وينتج عن هذا النهج التكيّفي معدّل طلبات أفضل مع خفض وقت الاستجابة للإجراءات التي يتخذها المستخدم.