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

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

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

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

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

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

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

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. अगर अनुरोध पूरा नहीं होता है, तो 2 + random_number_milliseconds तक इंतज़ार करें और अनुरोध को फिर से भेजें.
  4. अगर अनुरोध पूरा नहीं होता है, तो 4 + random_number_milliseconds तक इंतज़ार करें और अनुरोध को फिर से भेजें.
  5. इसी तरह, maximum_backoff समय तक इंतज़ार करें और अनुरोध को फिर से भेजें.
  6. अनुरोध को फिर से भेजने की तय की गई ज़्यादा से ज़्यादा संख्या तक इंतज़ार करें और अनुरोध को फिर से भेजें. हालांकि, फिर से भेजे जाने वाले अनुरोधों के बीच इंतज़ार की अवधि न बढ़ाएं.

कहां:

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

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

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

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

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

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

ज़्यादा जानने के लिए, ये संसाधन देखें: