इस्तेमाल करने की सीमा

Google Play EMM API में, हर EMM के लिए हर मिनट 60,000 क्वेरी की डिफ़ॉल्ट सीमा होती है.

कोटा से ज़्यादा अनुरोध करने पर, Google Play EMM API HTTP 429 Too Many Requests दिखाता है. इस्तेमाल की तय सीमा से ज़्यादा डेटा का इस्तेमाल न करने और अपने उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, यहां दिए गए सबसे सही तरीकों को अपनाएं.

एपीआई के इस्तेमाल की सीमाओं के अंदर रहने के लिए सुझाव

Google Play EMM API का इस्तेमाल करते समय, कुछ सबसे सही तरीके अपनाए जा सकते हैं. इनकी मदद से, अनुरोधों को डिस्ट्रिब्यूट किया जा सकता है और इस्तेमाल की सीमाओं को पार करने का जोखिम कम किया जा सकता है.

शुरू होने का समय और इंटरवल को रैंडम क्रम में सेट करना

एक ही समय पर डिवाइसों को सिंक करने या चेक-इन करने जैसी गतिविधियों की वजह से, अनुरोध की संख्या में काफ़ी बढ़ोतरी हो सकती है. इन गतिविधियों को नियमित तौर पर शेड्यूल किए गए इंटरवल पर करने के बजाय, इन इंटरवल को रैंडम तरीके से तय करके, अनुरोध का लोड बांटा जा सकता है. उदाहरण के लिए, हर डिवाइस को हर 24 घंटे में सिंक करने के बजाय, हर डिवाइस को 23 से 25 घंटे के बीच, किसी भी समय सिंक किया जा सकता है. इससे अनुरोधों की संख्या को कम करने में मदद मिलती है.

इसी तरह, अगर आपने हर दिन की जाने वाली कोई ऐसी जॉब सेट की है जो एक के बाद एक कई एपीआई कॉल करती है, तो हर दिन किसी भी समय जॉब शुरू करें. इससे, एक ही समय पर अपने सभी एंटरप्राइज़ ग्राहकों के लिए ज़्यादा अनुरोध नहीं किए जाएंगे.

फिर से अनुरोध करने के लिए एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करें

अगर कई एपीआई कॉल वाली जॉब चलाई जाती हैं, तो कोटा तक पहुंचने के लिए, एक्सपोनेंशियल बैकऑफ़ की रणनीति का इस्तेमाल करें. एक्सपोनेंशियल बैकऑफ़ एक ऐसा एल्गोरिदम है जो अनुरोधों को फिर से एक्सपोनेंशियल तरीके से आज़माता है. सामान्य एक्स्पोनेंशियल बैकऑफ़ लागू करने के फ़्लो का एक उदाहरण यह है:

1. Google Play के ईएमएम एपीआई को अनुरोध भेजें.
2. आपको HTTP 429 जवाब मिलेगा.
3. दो सेकंड इंतज़ार करें + random_time दबाएं. इसके बाद, फिर से कोशिश करें.
4. HTTP 429 जवाब पाएं.
5. चार सेकंड इंतज़ार करें + random_time, फिर अनुरोध दोबारा करें.
6. आपको HTTP 429 जवाब मिलेगा.
7. आठ सेकंड इंतज़ार करें + random_time दबाएं. इसके बाद, फिर से कोशिश करें.

आम तौर पर, random_time एक रैंडम संख्या होती है. यह -0.5 * इंतज़ार का समय से लेकर +0.5 * इंतज़ार का समय तक हो सकती है. अनुरोध दोबारा करने पर, हर बार एक नया random_time तय करें. उपयोगकर्ता को दी जाने वाली कार्रवाइयों को पूरा करने के लिए, एपीआई कॉल को ज़्यादा शेड्यूल (उदाहरण के लिए, 0.5, 1, और 2) पर फिर से करने की कोशिश की जा सकती है.

बैच प्रोसेस की दर तय करने की सीमा

जब भी बैच में की जाने वाली कोई प्रोसेस कोटा तक पहुंचती है, तो एपीआई को कॉल करने वाली उपयोगकर्ता कार्रवाइयों में लगने वाला समय बढ़ जाता है. ऐसी स्थितियों में, एक्सपोनेंशियल बैकऑफ़ जैसी रणनीतियां, उपयोगकर्ता की कार्रवाइयों के लिए कम इंतज़ार

एपीआई के इस्तेमाल की सीमाओं को बार-बार पूरा होने से रोकने और उपयोगकर्ताओं के लिए कार्रवाइयों में लगने वाले समय को बढ़ाने से बचने के लिए, एक साथ कई प्रोसेस करने के लिए, दर सीमित करने वाले टूल का इस्तेमाल करें. Google का RateLimiter देखें. रेट लिमिटर की मदद से, अपने एपीआई अनुरोधों की दर में बदलाव किया जा सकता है, ताकि आप लगातार इस्तेमाल की सीमा से नीचे रहें.

उदाहरण के लिए, 50 क्यूपीएस की डिफ़ॉल्ट दर सीमा के साथ, एक बैच प्रोसेस शुरू करें. जब तक एपीआई से आपको कोई गड़बड़ी नहीं मिलती, तब तक अनुरोधों की संख्या की सीमा को धीरे-धीरे बढ़ाएं (हर मिनट 1%). कोटा भर जाने पर, अनुरोध की दर को 20% कम कर दें. इस अडैप्टिव तरीके से, अनुरोध का अनुकूल रेट मिलता है. साथ ही, उपयोगकर्ताओं को होने वाली देरी को कम किया जाता है.