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

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

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

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

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

हर प्रोजेक्ट के लिए तय किए गए कोटे, 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

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

हर स्पेस के लिए तय किए गए कोटे, किसी स्पेस में क्वेरी की दर को सीमित करते हैं. साथ ही, ये कोटे उस स्पेस में काम करने वाले सभी 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

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

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 में एक की बढ़ोतरी होती है.
  • random_number_milliseconds, 1,000 से कम या इसके बराबर का कोई भी संख्या हो सकती है. इससे उन मामलों से बचा जा सकता है जिनमें कई क्लाइंट किसी वजह से सिंक हो जाते हैं और सभी एक साथ फिर से कोशिश करते हैं. साथ ही, सिंक किए गए अनुरोधों को एक साथ भेजते हैं. फिर से कोशिश करने के हर अनुरोध के बाद, random_number_milliseconds की वैल्यू का फिर से हिसाब लगाया जाता है.
  • आम तौर पर, maximum_backoff 32 या 64 सेकंड का होता है. सही वैल्यू, इस्तेमाल के उदाहरण पर निर्भर करती है.

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

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

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

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

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

ज़्यादा जानने के लिए, नीचे दिए गए लेख पढ़ें: