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

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

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

Chat API के तरीकों पर, कई तरह की तय सीमाएं लागू हो सकती हैं: हर प्रोजेक्ट के लिए, हर स्पेस के लिए, और हर उपयोगकर्ता के लिए तय सीमाएं.

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

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

इस टेबल में, हर प्रोजेक्ट के लिए क्वेरी की सीमाओं के बारे में बताया गया है. इन सीमाओं के बारे में जानने के लिए, कोटा पेज पर जाएं.

हर प्रोजेक्ट के लिए कोटा	Chat API के तरीके	सीमा (हर 60 सेकंड में)
हर मिनट में लिखे गए मैसेज	spaces.messages.create spaces.messages.patch spaces.messages.delete	3000
हर मिनट में पढ़े गए मैसेज	spaces.messages.get spaces.messages.list	3000
हर मिनट में सदस्यता लेने वाले लोगों की संख्या	spaces.members.create spaces.members.delete	300
हर मिनट में पढ़ी जाने वाली सदस्यताएं	spaces.members.get spaces.members.list	3000
स्पेस में हर मिनट में होने वाली राइट कार्रवाइयां	spaces.setup spaces.create spaces.patch spaces.delete	60
हर मिनट में पढ़ी गई स्पेस की संख्या	spaces.get spaces.list spaces.findDirectMessage	3000
हर मिनट में अटैचमेंट लिखने की संख्या	media.upload	600
हर मिनट में अटैचमेंट को पढ़ने की संख्या	spaces.messages.attachments.get media.download	3000
हर मिनट की जाने वाली प्रतिक्रियाएं	spaces.messages.reactions.create spaces.messages.reactions.delete	600
हर मिनट में पढ़ी गई प्रतिक्रियाएं	spaces.messages.reactions.list	3000

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

हर स्पेस के लिए तय किए गए कोटे, किसी स्पेस में क्वेरी की दर को सीमित करते हैं. साथ ही, ये कोटे उन सभी Chat ऐप्लिकेशन के साथ शेयर किए जाते हैं जो उस स्पेस में काम करते हैं. ये ऐप्लिकेशन, हर कोटे के लिए Chat API के तरीकों को कॉल करते हैं.

इस टेबल में, हर स्पेस के लिए क्वेरी की सीमाओं के बारे में बताया गया है:

हर स्पेस के लिए कोटा	Chat API के तरीके	सीमा (हर 60 सेकंड में)
रीड प्रति मिनट	media.download spaces.get spaces.members.get spaces.members.list spaces.messages.get spaces.messages.list spaces.messages.attachments.get spaces.messages.reactions.list	900
हर मिनट में लिखे गए शब्द	media.upload spaces.delete spaces.patch spaces.messages.create (इनकमिंग वेबहुक पर अतिरिक्त सीमाएं लागू होती हैं) spaces.messages.delete spaces.messages.patch spaces.messages.reactions.create spaces.messages.reactions.delete	60

हर उपयोगकर्ता के हिसाब से कोटा

हर उपयोगकर्ता के लिए तय किए गए कोटे से, Google Chat उपयोगकर्ता के लिए क्वेरी की दर सीमित हो जाती है. ये क्वेरी, उन सभी Chat ऐप्लिकेशन से जुड़ी होती हैं जो किसी उपयोगकर्ता की ओर से Chat API के किसी तरीके को कॉल करते हैं. इसके लिए, उपयोगकर्ता की पुष्टि का इस्तेमाल किया जाता है.

इस टेबल में, हर उपयोगकर्ता के लिए क्वेरी की सीमाओं के बारे में बताया गया है:

हर उपयोगकर्ता के लिए कोटा	Chat API के तरीके	सीमा (हर 60 सेकंड में)
रीड प्रति मिनट	customEmojis.get customEmojis.list	900
हर मिनट में लिखे गए शब्द	customEmojis.create customEmojis.delete	60

इस्तेमाल करने की अन्य सीमाएं

GROUP_CHAT टाइप के स्पेस बनाने के लिए, कोटे की कुछ और सीमाएं भी लागू होती हैं. इसके अलावा, SPACE टाइप के स्पेस बनाने के लिए भी कोटे की कुछ और सीमाएं लागू होती हैं. इन्हें spaces.create या spaces.setup में से किसी भी तरीके का इस्तेमाल करके बनाया जा सकता है. इस तरह के स्पेस, हर मिनट में 35 से कम और हर घंटे में 800 से कम बनाए जा सकते हैं. DIRECT_MESSAGE टाइप के स्पेस पर, कोटे की ये अतिरिक्त सीमाएं लागू नहीं होती हैं.

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

समय के हिसाब से तय किए गए कोटे से जुड़ी गड़बड़ियां ठीक करना

समय के आधार पर होने वाली सभी गड़बड़ियों (हर X मिनट में ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले और ट्रंकेटेड एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करे. इससे यह पक्का किया जा सकेगा कि आपके डिवाइस ज़्यादा लोड जनरेट न करें.

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

एल्गोरिदम का उदाहरण

एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को बार-बार भेजता है. इससे, अनुरोधों के बीच इंतज़ार का समय बढ़ता जाता है. यह इंतज़ार का समय, बैकऑफ़ के ज़्यादा से ज़्यादा समय तक बढ़ सकता है. उदाहरण के लिए:

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

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

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

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

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

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

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