Google Chat API एक शेयर की जाने वाली सेवा है. इसलिए, हम इस पर कोटा और सीमाएं लागू करते हैं. इससे यह पक्का किया जाता है कि सभी उपयोगकर्ता इसका सही तरीके से इस्तेमाल करें और Google Workspace की परफ़ॉर्मेंस बेहतर बनी रहे.
अगर आपने किसी कोटा की सीमा पार कर ली है, तो आपको 429: Too many requests एचटीटीपी स्टेटस कोड वाला जवाब मिलेगा. Chat के बैकएंड पर, रेट लिमिट की अतिरिक्त जांच करने पर भी, गड़बड़ी का यही जवाब मिल सकता है. अगर यह गड़बड़ी होती है, तो आपको
एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करना चाहिए
और कुछ समय बाद फिर से कोशिश करनी चाहिए. जब तक आप यहां दी गई टेबल में, हर मिनट के हिसाब से तय किए गए कोटे की सीमा में रहते हैं, तब तक हर दिन किए जा सकने वाले अनुरोधों की संख्या पर कोई पाबंदी नहीं होती.
Chat API के तरीकों पर, कई तरह के कोटे लागू हो सकते हैं: हर प्रोजेक्ट के लिए, हर स्पेस के लिए, और हर उपयोगकर्ता के लिए कोटे.
हर प्रोजेक्ट के लिए कोटे
हर प्रोजेक्ट के लिए कोटे, किसी Google Cloud प्रोजेक्ट के लिए क्वेरी की दर को सीमित करते हैं. इसलिए, ये कोटे Chat API के तय किए गए तरीकों को कॉल करने वाले, Chat के किसी एक ऐप्लिकेशन पर लागू होते हैं.
यहां दी गई टेबल में, हर प्रोजेक्ट के लिए क्वेरी की सीमाओं के बारे में बताया गया है. ये सीमाएं, कोटा पेज पर भी देखी जा सकती हैं.
हर प्रोजेक्ट के लिए कोटा |
Chat API के तरीके |
सीमा (हर 60 सेकंड में) |
|---|---|---|
हर मिनट में लिखे जाने वाले मैसेज की संख्या |
|
3000 |
हर मिनट में पढ़े जाने वाले मैसेज की संख्या |
|
3000 |
हर मिनट में जोड़ी जाने वाली मेंबरशिप की संख्या |
|
300 |
हर मिनट में पढ़ी जाने वाली मेंबरशिप की संख्या |
|
3000 |
हर मिनट में बनाए जाने वाले स्पेस की संख्या |
|
60 |
हर मिनट में पढ़े जाने वाले स्पेस की संख्या |
|
3000 |
हर मिनट में जोड़े जाने वाले अटैचमेंट की संख्या |
|
600 |
हर मिनट में पढ़े जाने वाले अटैचमेंट की संख्या |
|
3000 |
हर मिनट में जोड़ी जाने वाली प्रतिक्रियाओं की संख्या |
|
600 |
हर मिनट में पढ़ी जाने वाली प्रतिक्रियाओं की संख्या |
|
3000 |
हर मिनट में जोड़े जाने वाले कस्टम इमोजी की संख्या |
|
600 |
हर मिनट में पढ़े जाने वाले कस्टम इमोजी की संख्या |
|
3000 |
हर मिनट में जोड़े जाने वाले सेक्शन की संख्या |
|
600 |
हर मिनट में पढ़े जाने वाले सेक्शन की संख्या |
|
3000 |
हर स्पेस के लिए कोटे
हर स्पेस के लिए कोटे, किसी स्पेस में क्वेरी की दर को सीमित करते हैं. ये कोटे, Chat के उन सभी ऐप्लिकेशन के लिए शेयर किए जाते हैं जो उस स्पेस में काम करते हैं. साथ ही, ये कोटे Chat API के तय किए गए तरीकों को कॉल करने वाले हर ऐप्लिकेशन पर लागू होते हैं.
यहां दी गई टेबल में, हर स्पेस के लिए क्वेरी की सीमाओं के बारे में बताया गया है:
हर स्पेस के लिए कोटा |
Chat API के तरीके |
सीमा (हर सेकंड में) |
|---|---|---|
हर सेकंड में पढ़े जाने वाले मैसेज की संख्या |
|
15 |
हर सेकंड में लिखे जाने वाले मैसेज की संख्या |
|
1 |
हर सेकंड में जोड़ी जाने वाली प्रतिक्रियाओं की संख्या |
|
5 |
Google Chat में डेटा इंपोर्ट करते समय, हर सेकंड में लिखे जाने वाले मैसेज की संख्या |
|
10 |
हर उपयोगकर्ता के लिए कोटे
हर उपयोगकर्ता के लिए कोटे, Google Chat के किसी उपयोगकर्ता के लिए क्वेरी की दर को सीमित करते हैं. क्वेरी Chat के उन सभी ऐप्लिकेशन से जुड़ी होती हैं जो उपयोगकर्ता की ओर से Chat API के किसी तरीके को कॉल करते हैं. इसके लिए, उपयोगकर्ता की पुष्टि का इस्तेमाल किया जाता है.
यहां दी गई टेबल में, हर उपयोगकर्ता के लिए क्वेरी की सीमाओं के बारे में बताया गया है:
हर उपयोगकर्ता के लिए कोटा |
Chat API के तरीके |
सीमा (हर सेकंड में) |
|---|---|---|
हर सेकंड में जोड़े जाने वाले कस्टम इमोजी की संख्या |
|
1 |
हर सेकंड में पढ़े जाने वाले कस्टम इमोजी की संख्या |
|
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 समय पूरा होने के बाद भी, फिर से अनुरोध भेज सकता है.
इसके बाद, फिर से अनुरोध करने के लिए, बैकऑफ़ का समय बढ़ाने की ज़रूरत नहीं होती. उदाहरण के लिए, अगर कोई क्लाइंट maximum_backoff के लिए 64 सेकंड का समय इस्तेमाल करता है, तो इस वैल्यू तक पहुंचने के बाद, क्लाइंट हर 64 सेकंड में फिर से अनुरोध भेज सकता है. कुछ समय बाद,
क्लाइंट को हमेशा के लिए फिर से अनुरोध भेजने से रोका जाना चाहिए.
फिर से अनुरोध करने के बीच इंतज़ार का समय और फिर से अनुरोध करने की संख्या, आपके इस्तेमाल के उदाहरण और नेटवर्क की स्थितियों पर निर्भर करती है.
हर प्रोजेक्ट के लिए कोटा बढ़ाने का अनुरोध करना
अपने प्रोजेक्ट के संसाधन के इस्तेमाल के आधार पर, कोटा में बदलाव करने का अनुरोध किया जा सकता है. सेवा खाते से किए गए एपीआई कॉल को, एक ही खाते का इस्तेमाल माना जाता है. बदले हुए कोटे के लिए आवेदन करने का मतलब यह नहीं है कि इसे मंज़ूरी मिल ही जाएगी. कोटा में बदलाव के ऐसे अनुरोधों को मंज़ूरी मिलने में ज़्यादा समय लग सकता है जिनसे कोटा की वैल्यू में काफ़ी बढ़ोतरी हो सकती है.
सभी प्रोजेक्ट के लिए कोटे एक जैसे नहीं होते. समय के साथ-साथ, Google Cloud का इस्तेमाल बढ़ने पर, हो सकता है कि आपको कोटा की वैल्यू बढ़ाने की ज़रूरत पड़े. अगर आपको लगता है कि आने वाले समय में इस्तेमाल में काफ़ी बढ़ोतरी होगी, तो Google Cloud कंसोल में, कोटा और सिस्टम की सीमाएं पेज से, कोटा में बदलाव करने का अनुरोध किया जा सकता है.
ज़्यादा जानने के लिए, ये संसाधन देखें:
- कोटा में बदलाव के बारे में जानकारी
- कोटा के इस्तेमाल और सीमाओं की जानकारी देखना
- कोटा की सीमा बढ़ाने का अनुरोध करना