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