Google Chat API एक शेयर की गई सेवा है. इसलिए, हम इस पर कोटा और सीमाएं लागू करते हैं. इससे यह पक्का किया जा सकता है कि सभी उपयोगकर्ता इसका सही तरीके से इस्तेमाल करें. साथ ही, इससे Google Workspace की परफ़ॉर्मेंस को सुरक्षित रखा जा सकता है.
अगर आपने कोटा से ज़्यादा अनुरोध किए हैं, तो आपको 429: Too many requests एचटीटीपी स्टेटस कोड वाला जवाब मिलेगा. चैट के बैकएंड पर, अनुरोधों की संख्या की सीमा की अतिरिक्त जांच करने पर भी, एक जैसा गड़बड़ी वाला जवाब मिल सकता है. अगर यह गड़बड़ी होती है, तो आपको एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करना चाहिए. इसके बाद, कुछ समय बाद फिर से कोशिश करें. जब तक आप यहां दी गई टेबल में बताए गए, हर मिनट के कोटे के हिसाब से अनुरोध करते हैं, तब तक हर दिन किए जाने वाले अनुरोधों की संख्या पर कोई पाबंदी नहीं होती.
Chat API के तरीकों पर, कई तरह की तय सीमाएं लागू हो सकती हैं: हर प्रोजेक्ट के लिए, हर स्पेस के लिए, और हर उपयोगकर्ता के लिए तय सीमाएं.
हर प्रोजेक्ट के लिए कोटा
हर प्रोजेक्ट के लिए तय किए गए कोटे, Google Cloud प्रोजेक्ट के लिए क्वेरी की दर को सीमित करते हैं. इसलिए, ये कोटे किसी एक Chat ऐप्लिकेशन पर लागू होते हैं. यह ऐप्लिकेशन, हर कोटे के लिए Chat API के तय किए गए तरीकों को कॉल करता है.
इस टेबल में, हर प्रोजेक्ट के लिए क्वेरी की सीमाओं के बारे में जानकारी दी गई है. इन सीमाओं के बारे में जानने के लिए, कोटा पेज पर जाएं.
हर प्रोजेक्ट के लिए कोटा |
Chat API के तरीके |
सीमा (हर 60 सेकंड में) |
|---|---|---|
हर मिनट में लिखे गए मैसेज |
|
3000 |
हर मिनट में पढ़े गए मैसेज |
|
3000 |
हर मिनट के हिसाब से सदस्यता लेने वाले लोगों की संख्या |
|
300 |
हर मिनट में सदस्यता के हिसाब से पढ़े जाने वाले लेख |
|
3000 |
हर मिनट में स्पेस में लिखे गए डेटा की संख्या |
|
60 |
हर मिनट में पढ़ी गई स्पेस की संख्या |
|
3000 |
हर मिनट में अटैचमेंट लिखने की संख्या |
|
600 |
हर मिनट में अटैचमेंट पढ़ने की संख्या |
|
3000 |
हर मिनट में की गई प्रतिक्रियाओं की संख्या |
|
600 |
हर मिनट में पढ़ी गई प्रतिक्रियाओं की संख्या |
|
3000 |
CustomEmoji writes per minute |
|
600 |
CustomEmoji reads per minute |
|
3000 |
हर मिनट के हिसाब से सेक्शन में डेटा लिखने की संख्या |
|
600 |
हर मिनट के हिसाब से सेक्शन को पढ़ने की संख्या |
|
3000 |
हर स्पेस के लिए कोटा
हर स्पेस के लिए तय किए गए कोटे, किसी स्पेस में क्वेरी की दर को सीमित करते हैं. साथ ही, ये कोटे उस स्पेस में काम करने वाले सभी Chat ऐप्लिकेशन के साथ शेयर किए जाते हैं. ये ऐप्लिकेशन, हर कोटे के लिए Chat API के तरीकों को कॉल करते हैं.
इस टेबल में, हर स्पेस के लिए क्वेरी की सीमाओं के बारे में बताया गया है:
हर स्पेस के लिए कोटा |
Chat API के तरीके |
सीमा (हर सेकंड) |
|---|---|---|
रीड प्रति सेकंड |
|
15 |
प्रति सेकंड लिखने की संख्या |
|
1 |
हर सेकंड में की जाने वाली प्रतिक्रियाएं |
|
5 |
Google Chat में डेटा इंपोर्ट करते समय, हर सेकंड में लिखे जाने वाले मैसेज |
|
10 |
हर उपयोगकर्ता के हिसाब से कोटा
हर उपयोगकर्ता के लिए तय किए गए कोटे से, Google Chat उपयोगकर्ता के लिए क्वेरी की दर सीमित हो जाती है. ये क्वेरी, उन सभी Chat ऐप्लिकेशन से जुड़ी होती हैं जो किसी उपयोगकर्ता की ओर से Chat API के किसी तरीके को कॉल करते हैं. इसके लिए, उपयोगकर्ता की पुष्टि का इस्तेमाल किया जाता है.
इस टेबल में, हर उपयोगकर्ता के लिए क्वेरी की सीमाओं के बारे में बताया गया है:
हर उपयोगकर्ता के लिए कोटा |
Chat API के तरीके |
सीमा (हर सेकंड) |
|---|---|---|
CustomEmoji writes per second |
|
1 |
CustomEmoji reads per second |
|
15 |
हर सेकंड में सेक्शन में किए गए बदलाव |
|
1 |
हर सेकंड में पढ़े गए सेक्शन |
|
15 |
इस्तेमाल करने की अन्य सीमाएं
एक ही स्पेस को टारगेट करने वाले ज़्यादा एपीआई ट्रैफ़िक की वजह से, अतिरिक्त आंतरिक सीमाएं ट्रिगर हो सकती हैं. ये सीमाएं, कोटा पेज पर नहीं दिखती हैं.
समय के हिसाब से तय किए गए कोटे से जुड़ी गड़बड़ियां ठीक करना
समय के हिसाब से होने वाली सभी गड़बड़ियों (हर X मिनट में ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले और ट्रंकेटेड एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करे. इससे यह पक्का किया जा सकेगा कि आपके डिवाइस ज़्यादा लोड जनरेट न करें.
एक्सपोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी ठीक करने की एक स्टैंडर्ड रणनीति है. एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को फिर से भेजने की कोशिश करता है. इसके लिए, अनुरोधों के बीच इंतज़ार का समय तेज़ी से बढ़ता जाता है. यह इंतज़ार का ज़्यादा से ज़्यादा समय तक होता है. अगर अनुरोध अब भी पूरे नहीं हो रहे हैं, तो यह ज़रूरी है कि अनुरोधों के बीच का समय धीरे-धीरे बढ़ता जाए, ताकि अनुरोध पूरा हो सके.
एल्गोरिदम का उदाहरण
एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को बार-बार करता है. साथ ही, यह कोशिशों के बीच इंतज़ार के समय को बढ़ाता है. यह इंतज़ार का समय, बैकऑफ़ के ज़्यादा से ज़्यादा समय तक बढ़ सकता है. उदाहरण के लिए:
- Google Chat API को अनुरोध भेजें.
- अगर अनुरोध पूरा नहीं होता है, तो 1 +
random_number_millisecondsसेकंड इंतज़ार करें और फिर से अनुरोध करें. - अगर अनुरोध पूरा नहीं होता है, तो 2 +
random_number_millisecondsसेकंड इंतज़ार करें और फिर से अनुरोध करें. - अगर अनुरोध पूरा नहीं होता है, तो 4 +
random_number_millisecondsसेकंड इंतज़ार करें और फिर से अनुरोध करें. - और इसी तरह,
maximum_backoffबार तक. - कुछ समय तक इंतज़ार करें और ज़्यादा से ज़्यादा बार कोशिश करें. हालांकि, कोशिशों के बीच इंतज़ार की अवधि न बढ़ाएं.
कहां:
- आपको
min(((2^n)+random_number_milliseconds), maximum_backoff)तक इंतज़ार करना होगा. हर बार अनुरोध करने पर,nमें 1 की बढ़ोतरी होती है. random_number_milliseconds, 1,000 से कम या इसके बराबर मिलीसेकंड की कोई रैंडम संख्या है. इससे उन मामलों से बचने में मदद मिलती है जिनमें कई क्लाइंट किसी स्थिति के हिसाब से सिंक हो जाते हैं और सभी एक साथ फिर से कोशिश करते हैं. इससे अनुरोध, सिंक की गई वेव में भेजे जाते हैं. फिर से कोशिश करने के हर अनुरोध के बाद,random_number_millisecondsकी वैल्यू फिर से कैलकुलेट की जाती है.maximum_backoffकी अवधि आम तौर पर 32 या 64 सेकंड होती है. सही वैल्यू, इस्तेमाल के उदाहरण पर निर्भर करती है.
maximum_backoff बार कोशिश करने के बाद भी, क्लाइंट फिर से कोशिश कर सकता है.
इस पॉइंट के बाद, फिर से कोशिश करने पर बैकऑफ़ टाइम को बढ़ाने की ज़रूरत नहीं होती. उदाहरण के लिए, अगर कोई क्लाइंट 64 सेकंड का maximum_backoff इस्तेमाल करता है, तो इस वैल्यू तक पहुंचने के बाद, क्लाइंट हर 64 सेकंड में फिर से कोशिश कर सकता है. किसी समय, क्लाइंट को बार-बार कोशिश करने से रोका जाना चाहिए.
फिर से कोशिश करने के बीच इंतज़ार करने का समय और फिर से कोशिश करने की संख्या, आपके इस्तेमाल के उदाहरण और नेटवर्क की स्थितियों पर निर्भर करती है.
हर प्रोजेक्ट के लिए कोटा बढ़ाने का अनुरोध करना
प्रोजेक्ट में इस्तेमाल किए गए संसाधनों के आधार पर, हो सकता है कि आपको कोटा में बदलाव करने का अनुरोध करना पड़े. सेवा खाते से किए गए एपीआई कॉल को एक ही खाते से किया गया कॉल माना जाता है. बदले गए कोटे के लिए आवेदन करने का मतलब यह नहीं है कि आपको मंज़ूरी मिल जाएगी. कोटा अडजस्ट करने के ऐसे अनुरोधों को मंज़ूरी मिलने में ज़्यादा समय लग सकता है जिनसे कोटा वैल्यू में काफ़ी बढ़ोतरी होती है.
सभी प्रोजेक्ट के लिए, एक जैसे कोटा उपलब्ध नहीं होते. समय के साथ-साथ Google Cloud का इस्तेमाल बढ़ने पर, आपको कोटा की वैल्यू बढ़ाने की ज़रूरत पड़ सकती है. अगर आपको लगता है कि आने वाले समय में आपके इस्तेमाल में काफ़ी बढ़ोतरी होने वाली है, तो Google Cloud Console में कोटा पेज पर जाकर, कोटा में बदलाव करने का अनुरोध किया जा सकता है.
ज़्यादा जानने के लिए, यहां दिए गए संसाधन देखें:
- कोटा अडजस्टमेंट के बारे में जानकारी
- कोटा के मौजूदा इस्तेमाल और सीमाओं की जानकारी देखना
- कोटा बढ़ाने का अनुरोध करना