Google Calendar API के लिए कोटा तय किए गए हैं, ताकि सभी लोग इसका सही तरीके से इस्तेमाल कर सकें. Calendar API का इस्तेमाल करते समय, इन तीन ज़रूरी सीमाओं का ध्यान रखें:
एपीआई के इस्तेमाल से जुड़े कोटे: हर प्रोजेक्ट और हर उपयोगकर्ता के लिए लागू होते हैं. ज़्यादा जानकारी के लिए, Calendar API के इस्तेमाल के कोटा के टाइप देखें.
Google Calendar के इस्तेमाल की सामान्य सीमाएं: Google Calendar API एक शेयर की गई सेवा है. इसकी कुछ सीमाएं हैं, ताकि Google Workspace सिस्टम की परफ़ॉर्मेंस को सुरक्षित रखा जा सके. ज़्यादा जानकारी के लिए, Calendar के इस्तेमाल से जुड़ी सीमाएं लेख पढ़ें
ऑपरेशनल सीमाएं: इन सीमाओं में किसी भी समय बदलाव किया जा सकता है. उदाहरण के लिए, अगर किसी एक कैलेंडर में बहुत कम समय में कई बार बदलाव करने की कोशिश की जाती है.
Calendar API के लिए अनुरोध करने की सीमा
दो तरह के कोटा लागू किए जाते हैं:
हर प्रोजेक्ट के लिए हर मिनट: इससे यह पता चलता है कि आपका Google Cloud प्रोजेक्ट, एक मिनट में कितने अनुरोध कर सकता है.
हर उपयोगकर्ता के लिए, हर प्रोजेक्ट के हिसाब से हर मिनट में किए जा सकने वाले अनुरोधों की संख्या: यह उन अनुरोधों की संख्या है जो कोई उपयोगकर्ता आपके Cloud प्रोजेक्ट में कर सकता है. इस सीमा का मकसद, यह पक्का करने में आपकी मदद करना है कि आपके उपयोगकर्ताओं के बीच, ऐप्लिकेशन के इस्तेमाल को सही तरीके से बांटा जाए.
स्लाइडिंग विंडो का इस्तेमाल करके, हर मिनट के हिसाब से कोटे का हिसाब लगाया जाता है. अगर एक मिनट में, हर मिनट के हिसाब से तय किए गए कोटे से ज़्यादा ट्रैफ़िक आता है, तो अगले विंडो में दर सीमित कर दी जाएगी. इससे यह पक्का किया जा सकेगा कि आपका इस्तेमाल, औसतन कोटे के अंदर रहे.
यहां दी गई टेबल में, इन सीमाओं के बारे में बताया गया है:
| इस्तेमाल की सीमा का टाइप | सीमा |
|---|---|
| हर प्रोजेक्ट के लिए, हर मिनट | 10,000 अनुरोध |
| हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट | 600 अनुरोध |
रोज़ की बिलिंग सीमा
हर प्रोजेक्ट के लिए हर दिन तय की गई इस सीमा से पता चलता है कि 24 घंटे की अवधि में, आपका Google Cloud प्रोजेक्ट ज़्यादा से ज़्यादा कितने अनुरोध कर सकता है. इसके बाद, आपसे शुल्क लिया जाएगा.
इस थ्रेशोल्ड से कम इस्तेमाल करने पर, आपसे कोई अतिरिक्त शुल्क नहीं लिया जाता. साथ ही, आपके Google Cloud खाते के लिए बिल नहीं भेजा जाता. बिलिंग की पूरी जानकारी, 2026 में बाद में शेयर की जाएगी. साथ ही, बदलाव लागू होने से कम से कम 90 दिन पहले इसकी सूचना दी जाएगी.
हर रोज़ के थ्रेशोल्ड की इस सीमा को बढ़ाने का अनुरोध नहीं किया जा सकता.
इस टेबल में, सीमा के बारे में जानकारी दी गई है:
| थ्रेशोल्ड की सीमा का टाइप | सीमा |
|---|---|
| हर प्रोजेक्ट के लिए हर दिन | 10,00,000 अनुरोध |
ज़्यादा जानकारी के लिए, एजेंट टूल और एपीआई के लिए Google Workspace का स्टैंडर्ड मॉडल लेख पढ़ें.
समय के हिसाब से तय किए गए कोटे से जुड़ी गड़बड़ियां ठीक करना
समय के हिसाब से होने वाली सभी गड़बड़ियों (हर X मिनट में ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले और ट्रंकेटेड एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करे. इससे यह पक्का किया जा सकेगा कि आपके डिवाइस ज़्यादा लोड जनरेट न करें.
एक्सपोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी ठीक करने की एक स्टैंडर्ड रणनीति है. एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को फिर से भेजने की कोशिश करता है. इसके लिए, अनुरोधों के बीच इंतज़ार का समय तेज़ी से बढ़ता जाता है. यह इंतज़ार का ज़्यादा से ज़्यादा समय तक होता है. अगर अनुरोध अब भी पूरे नहीं हो रहे हैं, तो यह ज़रूरी है कि अनुरोधों के बीच का समय धीरे-धीरे बढ़ता जाए, ताकि अनुरोध पूरा हो सके.
एल्गोरिदम का उदाहरण
एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को बार-बार करता है. साथ ही, यह कोशिशों के बीच इंतज़ार के समय को बढ़ाता है. यह इंतज़ार का समय, बैकऑफ़ के ज़्यादा से ज़्यादा समय तक बढ़ सकता है. उदाहरण के लिए:
- Google Calendar API को अनुरोध भेजें.
- अगर अनुरोध पूरा नहीं होता है, तो 1 +
random_number_millisecondsसेकंड इंतज़ार करें और फिर से अनुरोध करें. - अगर अनुरोध पूरा नहीं होता है, तो 2 +
random_number_millisecondsसेकंड इंतज़ार करें और फिर से अनुरोध करें. - अगर अनुरोध पूरा नहीं होता है, तो 4 +
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 Calendar API का स्टैंडर्ड इस्तेमाल, बिना किसी अतिरिक्त शुल्क के किया जा सकता है. कोटा से ज़्यादा अनुरोध करने पर, 2026 के आखिर में आपके Google Cloud बिलिंग खाते से शुल्क लिया जाएगा. ज़्यादा जानकारी के लिए, एजेंट टूल और एपीआई के लिए Google Workspace का स्टैंडर्ड मॉडल लेख पढ़ें.
कोटा बढ़ाने का अनुरोध करना
अपने प्रोजेक्ट में इस्तेमाल किए गए संसाधनों के आधार पर, आपको कोटे में बदलाव करने का अनुरोध करना पड़ सकता है. किसी सेवा खाते से किए गए एपीआई कॉल को, एक ही खाते से किए गए कॉल माना जाता है. बदले गए कोटे के लिए आवेदन करने का मतलब यह नहीं है कि आपको मंज़ूरी मिल जाएगी. कोटा में बदलाव करने के ऐसे अनुरोधों को मंज़ूरी मिलने में ज़्यादा समय लग सकता है जिनसे कोटा वैल्यू में काफ़ी बढ़ोतरी होती है.
सभी प्रोजेक्ट के लिए, एक जैसे कोटा उपलब्ध नहीं होते. समय के साथ-साथ Google Cloud का इस्तेमाल बढ़ने पर, आपको कोटा की वैल्यू बढ़ाने की ज़रूरत पड़ सकती है. अगर आपको लगता है कि आने वाले समय में इस्तेमाल में काफ़ी बढ़ोतरी हो सकती है, तो Google Cloud Console में कोटा और सिस्टम की सीमाएं पेज पर जाकर, कोटे में बदलाव करने का अनुरोध किया जा सकता है.
ज़्यादा जानने के लिए, यहां दिए गए संसाधन देखें:
- कोटा अडजस्टमेंट के बारे में जानकारी
- कोटा के इस्तेमाल और सीमाओं की जानकारी देखना
- कोटा बढ़ाने का अनुरोध करना
समस्या हल करें
अगर इनमें से कोई भी कोटा पूरा हो जाता है, तो आपको दर की सीमा तय कर दी जाती है. साथ ही, आपकी क्वेरी के जवाब में 403
usageLimits स्टेटस कोड या 429
usageLimits स्टेटस कोड मिलता है.
ऐसा होने पर, ये तरीके आज़माए जा सकते हैं:
सभी सबसे सही तरीकों का पालन करना न भूलें: एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करें, ट्रैफ़िक पैटर्न को रैंडमाइज़ करें, और पुश नोटिफ़िकेशन का इस्तेमाल करें.
अगर आपके प्रोजेक्ट में उपयोगकर्ताओं की संख्या बढ़ रही है, तो कोटा बढ़ाने का अनुरोध किया जा सकता है.
अगर हर उपयोगकर्ता के लिए तय की गई कोटा सीमाएं पूरी हो जाती हैं, तो ये काम किए जा सकते हैं:
अगर सेवा खाते का इस्तेमाल किया जाता है, तो उपयोगकर्ताओं को लोड असाइन करें या इसे एक से ज़्यादा सेवा खातों के बीच बांटें.
हालांकि, हर उपयोगकर्ता के लिए कोटे को बढ़ाने का अनुरोध किया जा सकता है, लेकिन आम तौर पर, इसे डिफ़ॉल्ट वैल्यू से ज़्यादा बढ़ाने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि आपका ऐप्लिकेशन अन्य तरह की सीमाओं को पार कर सकता है. उदाहरण के लिए, कैलेंडर के सामान्य इस्तेमाल की सीमाएं या ऑपरेशनल सीमाएं.
सिर्फ़ टेस्ट के लिए एक अलग प्रोजेक्ट रजिस्टर करके, कोटे की सीमाओं को टेस्ट करें. इस प्रोजेक्ट का कॉन्फ़िगरेशन, आपके प्रोडक्शन प्रोजेक्ट के जैसा होना चाहिए. ज़्यादा जानकारी के लिए, टेस्ट कोटा की सीमा मैनेज करना लेख पढ़ें.
ट्रैफ़िक के पैटर्न को रैंडम करना
कैलेंडर क्लाइंट में, एक ही समय पर कई क्लाइंट के ऑपरेशन करने की वजह से, ट्रैफ़िक के पैटर्न में अचानक बढ़ोतरी हो सकती है. उदाहरण के लिए, Calendar क्लाइंट के लिए, आधी रात को पूरा सिंक करना एक सामान्य खराब तरीका है. इससे हर मिनट के लिए तय किए गए कोटे के खत्म होने की संभावना बढ़ जाती है. साथ ही, इससे दर सीमित हो जाती है और बैकऑफ़ की स्थिति पैदा हो जाती है.
ऐसा न हो, इसके लिए पक्का करें कि आपका ट्रैफ़िक पूरे दिन में फैला हो. अगर आपके क्लाइंट को हर दिन सिंक करना है, तो क्लाइंट को एक ऐसा समय तय करने के लिए कहें जो हर क्लाइंट के लिए अलग हो. अगर आपको कोई कार्रवाई नियमित तौर पर करनी है, तो इंटरवल में +/- 25% का अंतर रखें. इससे ट्रैफ़िक को ज़्यादा बेहतर तरीके से डिस्ट्रिब्यूट किया जा सकेगा और उपयोगकर्ताओं को बेहतर अनुभव मिलेगा.
पुश नोटिफ़िकेशन का इस्तेमाल करना
इसका इस्तेमाल आम तौर पर तब किया जाता है, जब उपयोगकर्ता के कैलेंडर में कोई बदलाव होने पर कोई कार्रवाई करनी हो. यहां एंटी-पैटर्न यह है कि हर कैलेंडर को बार-बार पोल किया जाए. इससे आपका पूरा कोटा बहुत जल्द खत्म हो जाएगा. उदाहरण के लिए, अगर आपके ऐप्लिकेशन के 5,000 उपयोगकर्ता हैं और वह हर उपयोगकर्ता के कैलेंडर को हर मिनट में एक बार पोल करता है, तो इसके लिए हर मिनट में कम से कम 5,000 का कोटा ज़रूरी है. भले ही, कोई काम न किया गया हो.
सर्वर-साइड ऐप्लिकेशन, पुश नोटिफ़िकेशन के लिए रजिस्टर कर सकते हैं. इससे हमें आपकी दिलचस्पी के हिसाब से सूचनाएं भेजने में मदद मिलती है. इन्हें सेट अप करने में ज़्यादा समय लगता है. हालांकि, इनकी मदद से अपने कोटे का ज़्यादा असरदार तरीके से इस्तेमाल किया जा सकता है. साथ ही, इनसे उपयोगकर्ता अनुभव को बेहतर बनाया जा सकता है. पक्का करें कि आपने उस eventType के बारे में बताया हो जिसके लिए आपको सूचना चाहिए. ज़्यादा जानकारी के लिए, पुश
नोटिफ़िकेशन देखें.
सेवा खातों के साथ सही तरीके से संसाधन असाइन करना
अगर आपका ऐप्लिकेशन, डोमेन-वाइड डेलिगेशन का इस्तेमाल करके अनुरोध कर रहा है, तो डिफ़ॉल्ट रूप से "प्रति मिनट प्रति उपयोगकर्ता प्रति प्रोजेक्ट" कोटे के लिए, सेवा खाते से शुल्क लिया जाता है. उस उपयोगकर्ता से नहीं जिसका इस्तेमाल करके अनुरोध किया जा रहा है. इसका मतलब है कि सेवा खाते का कोटा खत्म हो जाएगा और उस पर दर सीमा लागू हो जाएगी. भले ही, वह कई उपयोगकर्ताओं के कैलेंडर पर काम कर रहा हो.
quotaUser यूआरएल पैरामीटर या x-goog-quota-user एचटीटीपी हेडर का इस्तेमाल करके, यह बताया जा सकता है कि किस उपयोगकर्ता से शुल्क लिया गया है. इसका इस्तेमाल सिर्फ़ कोटा की गिनती के लिए किया जाता है. ज़्यादा जानकारी के लिए, हर उपयोगकर्ता के लिए अनुरोधों की संख्या सीमित करना लेख पढ़ें.
कोटा की सीमा को मैनेज करने की सुविधा की जांच करना
यह पक्का करने के लिए कि आपका ऐप्लिकेशन, कोटे की सीमाएं पूरी होने पर ठीक से काम कर सके (उदाहरण के लिए, एक्सपोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के ज़रिए) और आपके उपयोगकर्ताओं को किसी भी तरह की संभावित समस्याओं को कम करने के लिए, हमारा सुझाव है कि आप अपने इस्तेमाल के उदाहरण को असली एनवायरमेंट में टेस्ट करें.
हमारा सुझाव है कि आप Google Cloud Console में, सिर्फ़ जांच के लिए एक अलग प्रोजेक्ट रजिस्टर करें. इसके बाद, OAuth सहमति स्क्रीन को कॉन्फ़िगर करें. ऐसा अपने प्रोडक्शन प्रोजेक्ट की तरह करें, ताकि आपके ऐप्लिकेशन के असली इस्तेमाल में कोई रुकावट न आए. इसके बाद, इस प्रोजेक्ट के लिए कोटा की सीमाएं तय की जा सकती हैं. साथ ही, अपने ऐप्लिकेशन के व्यवहार पर नज़र रखी जा सकती है.