सीमाएं और कोटा, Google के इंफ़्रास्ट्रक्चर को ऐसी ऑटोमेटेड प्रोसेस से बचाते हैं जो Admin Settings API का गलत तरीके से इस्तेमाल करती है. किसी एपीआई से बहुत ज़्यादा अनुरोध, किसी सामान्य टाइपो की वजह से हो सकते हैं. इसके अलावा, यह भी हो सकता है कि सिस्टम को इस तरह से डिज़ाइन किया गया हो कि वह बिना किसी वजह के एपीआई कॉल करता हो. वजह चाहे जो भी हो, Google Workspace सिस्टम को सही तरीके से काम करने के लिए, किसी खास सोर्स से आने वाले ट्रैफ़िक को एक तय सीमा के बाद ब्लॉक करना ज़रूरी है. इससे यह पक्का किया जाता है कि किसी डेवलपर की कार्रवाइयों से, बड़े समुदाय पर बुरा असर न पड़े.
अगर आपका एपीआई अनुरोध पूरा नहीं होता है, तो आपको एचटीटीपी स्टेटस कोड का जवाब मिलेगा. 403 स्टेटस कोड में, गलत इनपुट के बारे में गड़बड़ी की जानकारी होती है. वहीं, 503 एचटीटीपी स्टेटस कोड में, गड़बड़ी की ऐसी जानकारी होती है जिससे पता चलता है कि एपीआई के किन कोटा को पार कर लिया गया है. इन जवाबों की मदद से, आपका कस्टम ऐप्लिकेशन इन गड़बड़ियों का पता लगा सकता है और ज़रूरी कार्रवाई कर सकता है.
अगर आपके अनुरोधों को तय समय में पूरा करना है, तो अपने अनुरोधों को एक साथ भेजें या अपने Java या C# ऐप्लिकेशन में कई थ्रेड का इस्तेमाल करें. उदाहरण के लिए, अपने अनुरोधों को महीने या किसी अन्य समयावधि के हिसाब से बांटें. थ्रेड के मामले में, हर अनुरोध के लिए एक थ्रेड का इस्तेमाल करके, 10 थ्रेड से शुरुआत करें. ध्यान दें कि थ्रेड के सुझावों के कुछ फ़ायदे और कुछ नुकसान होते हैं. साथ ही, ये एपीआई से जुड़ी सभी स्थितियों के लिए काम के नहीं होते. अनुरोधों की संख्या बहुत ज़्यादा होने पर, कोटे से जुड़ी गड़बड़ियां होंगी.
समय पर आधारित सभी गड़बड़ियों (हर थ्रेड के लिए X सेकंड में ज़्यादा से ज़्यादा N चीज़ें) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले. साथ ही, एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करके, फ़ेल हुए कॉल को फिर से आज़माने से पहले कुछ समय इंतज़ार करे. खास तौर पर, 503 स्टेटस कोड वाली गड़बड़ियों के लिए ऐसा करें. किसी थ्रेड के लिए, Email Settings API का एक उदाहरण यह है कि पांच सेकंड इंतज़ार करें और कॉल पूरा न होने पर फिर से कोशिश करें. अगर अनुरोध पूरा हो जाता है, तो अन्य थ्रेड के लिए भी इसी पैटर्न को दोहराएं. अगर दूसरा अनुरोध पूरा नहीं होता है, तो आपके ऐप्लिकेशन को अनुरोध की फ़्रीक्वेंसी को तब तक कम करना चाहिए, जब तक कॉल पूरा न हो जाए. उदाहरण के लिए, कॉल शुरू होने में लगने वाले शुरुआती पांच सेकंड के समय को बढ़ाकर 10 सेकंड करें. इसके बाद, कॉल करने की कोशिश फिर से करें. इसके अलावा, फिर से कोशिश करने की सीमा तय करें. उदाहरण के लिए, आपका ऐप्लिकेशन उपयोगकर्ता को गड़बड़ी का मैसेज दिखाता है. इससे पहले, अनुरोध को पांच से सात बार फिर से भेजें. हर बार अनुरोध भेजने के बीच में अलग-अलग समय का अंतर रखें.
| एपीआई कोटा की कैटगरी | कोटा |
|---|---|
| ClientLogin की मदद से पुष्टि करने वाले टोकन | यह कोड 24 घंटे के लिए मान्य है. गड़बड़ी का मैसेज '401 टोकन की समयसीमा खत्म हो गई है' है. |
| सार्वजनिक और निजी पासकोड जनरेट करना |
अपने आइडेंटिटी प्रोवाइडर की मदद से, DSA या RSA एल्गोरिदम का इस्तेमाल करके, सार्वजनिक और निजी कुंजियों का एक सेट जनरेट करें. सार्वजनिक पासकोड, X.509 फ़ॉर्मैट वाले सर्टिफ़िकेट में है. एसएएमएल पर आधारित सिंगल साइन-ऑन के लिए इस्तेमाल होने वाले हस्ताक्षर करने के कुंजियों के बारे में ज़्यादा जानने के लिए, Google Workspace की सिंगल साइन-ऑन सेवा के लिए कुंजियां और सर्टिफ़िकेट जनरेट करना लेख पढ़ें. |
| लोगो |
खाते के लोगो की इमेज फ़ाइल, JPEG, PNG या GIF फ़ॉर्मैट में हो सकती है. हमारा सुझाव है कि लोगो का साइज़ 143 x 59 पिक्सल का हो. साथ ही, फ़ाइल का साइज़ 20 केबी से कम होना चाहिए. कस्टम लोगो का इस्तेमाल करते समय, Google की सेवा की शर्तों का पालन करना न भूलें. साथ ही, Google के लोगो, Gmail के लोगो या Google के किसी अन्य लोगो का इस्तेमाल न करें. ज़्यादा जानकारी के लिए, लोगो और लैंडिंग पेज की नीतियां देखें. |
| ssoWhitelist |
ssoWhitelist, क्लासलेस इंटर-डोमेन रूटिंग (सीआईडीआर) फ़ॉर्मैट में नेटवर्क मास्क आईपी पता होता है. |
| अन्य तरह की सीमाएं | सीमाएं और दिशा-निर्देश |
|---|---|
| MX रिकॉर्ड की पुष्टि का स्टेटस |
MX रिकॉर्ड की पुष्टि करने की डिफ़ॉल्ट स्थिति `false` होती है. इसका मतलब है कि Google सिस्टम ने हाल ही में आपके MX रिकॉर्ड कॉन्फ़िगरेशन की जांच नहीं की है या आपके MX रिकॉर्ड, Google सिस्टम को पॉइंट करने के लिए कॉन्फ़िगर नहीं किए गए हैं. अगर आपने अपने रिकॉर्ड अपडेट कर दिए हैं और पुष्टि की स्थिति अब भी 'गलत' दिख रही है, तो इसका मतलब यह हो सकता है कि आपके MX रिकॉर्ड अपडेट लागू नहीं हुए हैं या रिकॉर्ड में टाइपिंग की कोई गड़बड़ी है. हमारा सुझाव है कि आप MX रिकॉर्ड के टाइम टू लाइव वैल्यू (टीटीएल) के हिसाब से तय किए गए समय तक इंतज़ार करें और फिर से कोशिश करें. |
| Country codes |
अगर संगठन के नाम को पसंद के मुताबिक नहीं बनाया गया है, तो डिफ़ॉल्ट रूप से आपका प्राइमरी डोमेन नेम दिखेगा. संगठन के नाम में इस्तेमाल किए जाने वाले वर्णों के बारे में जानकारी के लिए, वर्णों का इस्तेमाल लेख पढ़ें. |
creationTime प्रॉपर्टी, तारीख और समय को संख्या के तौर पर दिखाती है |
तारीख और समय के संख्यात्मक फ़ॉर्मैट के बारे में जानने के लिए, ISO 8601 देखें. |
| भाषा की जानकारी देने वाले टैग |
Google Mail में इस्तेमाल किए जा सकने वाले RFC 3066 भाषा के टैग देखें. |
| संगठन का नाम |
अगर संगठन के नाम को पसंद के मुताबिक नहीं बनाया गया है, तो डिफ़ॉल्ट रूप से आपका प्राइमरी डोमेन नेम दिखेगा. संगठन के नाम में इस्तेमाल किए जाने वाले वर्णों के बारे में जानकारी के लिए, वर्णों का इस्तेमाल लेख पढ़ें. |
हर प्रोजेक्ट के लिए कोटा बढ़ाने का अनुरोध करना
प्रोजेक्ट में इस्तेमाल किए गए संसाधनों के आधार पर, हो सकता है कि आपको कोटा में बदलाव करने का अनुरोध करना पड़े. सेवा खाते से किए गए एपीआई कॉल को एक ही खाते से किया गया कॉल माना जाता है. बदले गए कोटे के लिए आवेदन करने का मतलब यह नहीं है कि आपको मंज़ूरी मिल जाएगी. कोटा अडजस्ट करने के ऐसे अनुरोधों को मंज़ूरी मिलने में ज़्यादा समय लग सकता है जिनसे कोटा वैल्यू में काफ़ी बढ़ोतरी होती है.
सभी प्रोजेक्ट के लिए, एक जैसे कोटा उपलब्ध नहीं होते. समय के साथ-साथ Google Cloud का इस्तेमाल बढ़ने पर, आपको कोटा की वैल्यू बढ़ाने की ज़रूरत पड़ सकती है. अगर आपको लगता है कि आने वाले समय में आपके इस्तेमाल में काफ़ी बढ़ोतरी होने वाली है, तो Google Cloud Console में कोटा पेज पर जाकर, कोटा में बदलाव करने का अनुरोध किया जा सकता है.
ज़्यादा जानने के लिए, यहां दिए गए संसाधन देखें:
- कोटा अडजस्टमेंट के बारे में जानकारी
- कोटा के मौजूदा इस्तेमाल और सीमाओं की जानकारी देखना
- कोटा बढ़ाने का अनुरोध करना