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

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

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

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

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

हर स्पेस का कोटा, किसी स्पेस में क्वेरी की दर को सीमित करता है. साथ ही, इनके बीच शेयर किया जाता है उस स्पेस में, सूची में शामिल सभी चैट ऐप्लिकेशन को कॉल किया जा रहा है हर कोटा के लिए 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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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