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

Google Workspace इवेंट एपीआई एक शेयर की गई सेवा है. इसलिए, हम कोटा और सीमाएं लागू करते हैं, ताकि सभी उपयोगकर्ता इसका इस्तेमाल सही तरीके से कर सकें. साथ ही, Google Workspace की परफ़ॉर्मेंस को सुरक्षित रखा जा सके.

तय कोटे से ज़्यादा अनुरोध करने पर, आपको 429: Too many requests एचटीटीपी स्टेटस कोड वाला जवाब मिलेगा. Google Workspace इवेंट एपीआई के बैकएंड पर, अनुरोध करने की दर की सीमा की अन्य जांच करने पर भी गड़बड़ी का वही जवाब मिल सकता है. अगर यह गड़बड़ी होती है, तो आपको एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करना चाहिए और कुछ देर बाद कोशिश करें. जब तक इन टेबल में दी गई, हर मिनट के लिए दिए गए कोटे के अंदर ही रहेगा, तब तक हर दिन कितने भी अनुरोध किए जा सकते हैं.

हर प्रोजेक्ट के लिए कोटा

हर प्रोजेक्ट के लिए कोटा से, Google Cloud प्रोजेक्ट के लिए क्वेरी की दर सीमित हो जाती है. इस तरह, यह कोटा सिर्फ़ एक ऐप्लिकेशन पर लागू होता है जो हर कोटे के लिए, Google Workspace Events API में अलग-अलग तरीकों का इस्तेमाल करता है.

नीचे दी गई टेबल में, हर प्रोजेक्ट के लिए क्वेरी की सीमाओं की जानकारी दी गई है. Google Cloud Console में, कोटा पेज पर जाकर भी इन सीमाओं की जानकारी देखी जा सकती है.

हर प्रोजेक्ट के लिए कोटा	Google Workspace इवेंट एपीआई के तरीके	सीमा
प्रति मिनट लिखें	Subscriptions.create Subscriptions.patch Subscriptions.delete Subscriptions.reactivate	600
हर मिनट, हर उपयोगकर्ता के हिसाब से लिखें	Subscriptions.create Subscriptions.patch Subscriptions.delete Subscriptions.reactivate	100
हर मिनट पढ़ा जाता है	Subscriptions.get Subscriptions.list	600
हर मिनट, हर उपयोगकर्ता के हिसाब से पढ़ना	Subscriptions.get Subscriptions.list	100

समय पर आधारित कोटा से जुड़ी गड़बड़ियां ठीक करना

सभी समय के हिसाब से होने वाली गड़बड़ियों (हर X मिनट के लिए ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पहचान लें. साथ ही, काटा गया एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करें, ताकि आपके डिवाइस पर बहुत ज़्यादा लोड न हो.

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

एल्गोरिदम के उदाहरण

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

1. Google Workspace Events API को अनुरोध करें.
2. अगर अनुरोध पूरा नहीं हो पाता, तो एक और random_number_milliseconds इंतज़ार करें और फिर से कोशिश करें.
3. अगर अनुरोध पूरा नहीं हो पाता है, तो दो और random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करें.
4. अगर अनुरोध पूरा नहीं हो पाता है, तो चार और random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करें.
5. इसकी तरह, maximum_backoff बार तक.
6. ज़्यादा से ज़्यादा संख्या तक इंतज़ार करें और फिर से कोशिश करें. हालांकि, बार-बार की जाने वाली कोशिशों के बीच इंतज़ार की अवधि को न बढ़ाएं.

कहां:

• इंतज़ार का समय min(((2^n)+random_number_milliseconds), maximum_backoff) है. हर बार दोहराए जाने (अनुरोध) के लिए, n में एक की बढ़ोतरी हुई है.
• random_number_milliseconds, 1,000 से कम या उसके बराबर मिलीसेकंड की एक रैंडम संख्या है. इससे ऐसे मामलों से बचने में मदद मिलती है जिनमें कई क्लाइंट किसी स्थिति में सिंक किए जाते हैं. साथ ही, सभी एक साथ फिर से कोशिश करके, सिंक किए गए वेव में अनुरोध भेजते हैं. हर बार फिर से कोशिश करने के अनुरोध के बाद, random_number_milliseconds की वैल्यू का फिर से हिसाब लगाया जाता है.
• आम तौर पर, maximum_backoff की अवधि 32 या 64 सेकंड होती है. सही वैल्यू, इस्तेमाल के उदाहरण के हिसाब से तय की जाती है.

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

बार-बार की जाने वाली कोशिशों के बीच इंतज़ार का समय, आपके इस्तेमाल के उदाहरण और नेटवर्क की स्थिति पर निर्भर करता है.

हर प्रोजेक्ट के लिए कोटा बढ़ाने का अनुरोध करना

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

सभी प्रोजेक्ट का कोटा एक जैसा नहीं होता. समय के साथ Google Cloud का इस्तेमाल बढ़ने से, कोटे को बढ़ाना पड़ सकता है. अगर आपको आने वाले समय में, एट्रिब्यूट के इस्तेमाल में काफ़ी बढ़ोतरी होने की उम्मीद है, तो Google Cloud Console में मौजूद कोटा पेज पर जाकर, कोटा घटाने या बढ़ाने का अनुरोध किया जा सकता है.

ज़्यादा जानकारी के लिए, यहां दिए गए लेख पढ़ें:

• कोटा बढ़ाने के अनुरोधों के बारे में जानकारी
• अपने कोटा के इस्तेमाल की मौजूदा सीमा और उसकी सीमाएं देखना
• कोटे की सीमा को बढ़ाने का अनुरोध करना