Google Chat API, शेयर की जाने वाली सेवा है. इसलिए, हम इसमें कोटा और सीमाएं लागू करते हैं, ताकि सभी लोग इसका सही इस्तेमाल कर सकें. साथ ही, Google Workspace की परफ़ॉर्मेंस को सुरक्षित रखा जा सके.
कोटा से ज़्यादा अनुरोध करने पर, आपको 429: Too many requests
एचटीटीपी स्टेटस कोड रिस्पॉन्स मिलेगा. Chat बैकएंड पर, दर की सीमा की अन्य जांच से भी वही गड़बड़ी जवाब मिल सकता है. अगर यह गड़बड़ी होती है, तो आपको एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करना चाहिए और बाद में फिर से कोशिश करनी चाहिए. अगर आपने यहां दी गई टेबल में दिए गए हर मिनट के कोटे के दायरे में
बनाया है, तो हर दिन जितनी बार अनुरोध किया जा सकता है उसकी कोई सीमा नहीं है.
Chat API के तरीकों पर दो तरह के कोटा लागू होते हैं: हर स्पेस और हर प्रोजेक्ट के लिए कोटा.
हर स्पेस के लिए कोटा
हर स्पेस के लिए तय किए गए कोटे, किसी स्पेस में क्वेरी की दर को सीमित करते हैं. साथ ही, ये कोटे उस स्पेस में काम करने वाले सभी Chat ऐप्लिकेशन के बीच शेयर किए जाते हैं. ये ऐप्लिकेशन, हर कोटे के लिए सूची में दिए गए Chat API के तरीकों को कॉल करते हैं.
इस टेबल में, हर स्पेस के लिए क्वेरी की सीमाओं के बारे में बताया गया है:
हर स्पेस के लिए कोटा |
Chat API के तरीके |
सीमित (हर 60 सेकंड में, |
---|---|---|
पढ़ने की संख्या प्रति मिनट |
|
900 |
हर मिनट में लिखे गए शब्द |
|
60 |
हर प्रोजेक्ट के लिए कोटा
हर प्रोजेक्ट के लिए तय किए गए कोटे, Google Cloud प्रोजेक्ट के लिए क्वेरी की दर को सीमित करते हैं. इसलिए, ये कोटे, हर कोटे के लिए तय किए गए Chat API के तरीकों को कॉल करने वाले किसी एक Chat ऐप्लिकेशन पर लागू होते हैं.
नीचे दी गई टेबल में, हर प्रोजेक्ट के लिए क्वेरी की सीमाओं के बारे में बताया गया है. आपको ये सीमाएं, कोटा पेज पर भी दिखेंगी.
हर प्रोजेक्ट के लिए कोटा |
Chat API के तरीके |
सीमा (हर 60 सेकंड के लिए) |
---|---|---|
हर मिनट लिखे गए मैसेज |
|
3000 |
हर मिनट में पढ़े गए मैसेज |
|
3000 |
सदस्यता में हर मिनट बदलाव होने की दर |
|
300 |
हर मिनट में पढ़े गए शब्द |
|
3000 |
स्पेस में हर मिनट लिखे गए शब्द |
|
60 |
हर मिनट में Space से पढ़े गए शब्द |
|
3000 |
अटैचमेंट हर मिनट में लिखा जाता है |
|
600 |
हर मिनट में अटैचमेंट पढ़ने की दर |
|
3000 |
प्रति मिनट प्रतिक्रियाओं की संख्या |
|
600 |
हर मिनट प्रतिक्रिया के लिए पढ़े जाने की संख्या |
|
3000 |
इस्तेमाल से जुड़ी अन्य सीमाएं
spaces.create
या spaces.setup
तरीके का इस्तेमाल करके, GROUP_CHAT
या SPACE
टाइप के स्पेस बनाने के लिए, कोटा की अन्य सीमाएं भी हैं.
हर मिनट में 35 से कम और हर घंटे 800 से कम स्पेस बनाएं. DIRECT_MESSAGE
टाइप के स्पेस पर, कोटा के लिए तय की गई अतिरिक्त सीमाएं लागू नहीं होतीं.
एक ही स्पेस को टारगेट करने वाले ज़्यादा एपीआई ट्रैफ़िक की वजह से, ऐसी अन्य इंटरनल सीमाएं ट्रिगर हो सकती हैं जो कोटा पेज पर नहीं दिखती हैं.
समय के हिसाब से कोटे की गड़बड़ियां ठीक करना
समय के हिसाब से होने वाली सभी गड़बड़ियों (हर X मिनट में ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले और ट्रिगर होने में लगने वाले समय को कम करने के लिए, बैकऑफ़ का इस्तेमाल करे. इससे यह पक्का किया जा सकेगा कि आपके डिवाइसों पर ज़्यादा लोड न जनरेट हो.
एक्सपोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी को मैनेज करने की स्टैंडर्ड रणनीति है. एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों के बीच एक्सपोनेंशियल तौर पर बढ़ते इंतज़ार के समय का इस्तेमाल करके, अनुरोधों को फिर से भेजता है. यह ऐसा तब तक करता है, जब तक कि बैकऑफ़ का ज़्यादा से ज़्यादा समय नहीं हो जाता. अगर अनुरोध अब भी पूरे नहीं होते हैं, तो यह ज़रूरी है कि अनुरोध स्वीकार होने तक, अनुरोधों के बीच में लगने वाला समय बढ़ जाए.
एल्गोरिदम का उदाहरण
एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को एक्सपोनेंशियल तरीके से दोबारा भेजता है. इससे, दोबारा भेजे जाने के बीच इंतज़ार का समय बढ़ जाता है. यह इंतज़ार का समय, बैकऑफ़ के ज़्यादा से ज़्यादा समय तक हो सकता है. उदाहरण के लिए:
- Google Chat API को अनुरोध भेजें.
- अगर अनुरोध पूरा नहीं होता है, तो 1 +
random_number_milliseconds
इंतज़ार करें और फिर से अनुरोध करें. - अगर अनुरोध पूरा नहीं होता है, तो दो +
random_number_milliseconds
इंतज़ार करें और फिर से अनुरोध करें. - अगर अनुरोध पूरा नहीं होता है, तो चार +
random_number_milliseconds
इंतज़ार करें और फिर से अनुरोध करें. - इसी तरह, एक
maximum_backoff
बार तक. - कोशिश करते रहें और तय की गई ज़्यादा से ज़्यादा संख्या तक कोशिश करते रहें. हालांकि, बार-बार कोशिश करने के बीच में इंतज़ार का समय न बढ़ाएं.
कहां:
- इंतज़ार का समय
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 में कोटा पेज पर जाएं.
ज़्यादा जानकारी के लिए, इन संसाधनों को देखें:
- कोटा बढ़ाने के अनुरोधों के बारे में जानकारी
- अपने मौजूदा कोटा के इस्तेमाल और सीमाओं को देखना
- कोटे की सीमा बढ़ाने का अनुरोध करना