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

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

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

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

Google Play EMM API का इस्तेमाल करते समय, कुछ सबसे सही तरीके दिए गए हैं. इनकी मदद से, अनुरोधों को लोगों तक पहुंचाने के साथ-साथ इस्तेमाल करने की सीमाओं से ज़्यादा होने के जोखिम को कम किया जा सकता है.

शुरुआत के समय और इंटरवल किसी भी समय सेट करें

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

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

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

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

1. Google Play EMM API पर अनुरोध करें.
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% तक कम करें. यह अडैप्टिव व्यू, अनुरोध करने की दर को ज़्यादा बेहतर बनाता है. साथ ही, उपयोगकर्ताओं को दिखने वाली कार्रवाइयों के लिए इंतज़ार का समय कम करता है.