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

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

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

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

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

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

हर प्रोजेक्ट के लिए कोटा	Google Workspace Events API के तरीके	सीमा
हर मिनट में लिखे गए शब्द	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. अगर अनुरोध पूरा नहीं होता है, तो 1 + 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 समय पूरा होने के बाद, क्लाइंट फिर से कोशिश कर सकता है. इसके बाद, कोशिश करने के लिए बैकऑफ़ समय को लगातार बढ़ाने की ज़रूरत नहीं है. उदाहरण के लिए, अगर कोई क्लाइंट maximum_backoff के लिए 64 सेकंड का समय इस्तेमाल करता है, तो इस वैल्यू तक पहुंचने के बाद, क्लाइंट हर 64 सेकंड में फिर से कोशिश कर सकता है. किसी समय, क्लाइंट को बार-बार कोशिश करने से रोका जाना चाहिए.

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

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

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

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

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

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