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

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

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

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

हर स्पेस कोटा

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

हर स्पेस क्वेरी की सीमाओं के बारे में नीचे दी गई जानकारी:

प्रति-स्थान कोटा	Chat एपीआई के तरीके	सीमा (हर 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 Cloud प्रोजेक्ट के लिए क्वेरी की दर तय होती है. इस तरह से एक Chat ऐप्लिकेशन पर हर कोटे के लिए Chat API के बताए गए तरीके इस्तेमाल किए जाते हैं.

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

हर प्रोजेक्ट कोटा	Chat एपीआई के तरीके	सीमा (हर 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

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

GROUP_CHAT या SPACE टाइप (spaces.create या spaces.setup तरीके का इस्तेमाल करके) स्पेस बनाने के लिए, अतिरिक्त कोटा सीमाएं तय की गई हैं. हर मिनट में 35 स्पेस से कम और इस तरह के हर घंटे के लिए 210 स्पेस बनाएं. DIRECT_MESSAGE टाइप के स्पेस पर, ये अतिरिक्त कोटे की सीमाएं लागू नहीं होतीं.

एक ही स्पेस को टारगेट करने वाले किसी भी एपीआई के हर सेकंड में बड़ी क्वेरी (क्यूपीएस) से, अतिरिक्त अंदरूनी सीमाएं ट्रिगर हो सकती हैं. ये सीमाएं कोटा पेज पर नहीं दिखती हैं.

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

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

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

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

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

1. Google Chat API से अनुरोध करें.
2. अगर अनुरोध पूरा नहीं होता है, तो 1 + random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
3. अगर अनुरोध पूरा नहीं होता है, तो दो से ज़्यादा random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
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 के कोटा पेज पर जाकर, कोटा घटाने या बढ़ाने का अनुरोध किया जा सकता है.

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

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