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