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

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

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

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

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

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

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

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

Chat API के तरीके

सीमित (हर 60 सेकंड में,
स्पेस में मौजूद सभी Chat ऐप्लिकेशन के बीच शेयर किया जाता है)

पढ़ने की संख्या प्रति मिनट

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 API के तरीकों को कॉल करने वाले किसी एक Chat ऐप्लिकेशन पर लागू होते हैं.

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

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

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

हर मिनट में Space से पढ़े गए शब्द

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

इस्तेमाल से जुड़ी अन्य सीमाएं

spaces.create या spaces.setup तरीके का इस्तेमाल करके, GROUP_CHAT या SPACE टाइप के स्पेस बनाने के लिए, कोटा की अन्य सीमाएं भी हैं. हर मिनट में 35 से कम और हर घंटे 800 से कम स्पेस बनाएं. 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 में कोटा पेज पर जाएं.

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