सीमाएं और कोटा, Google के इन्फ़्रास्ट्रक्चर को ऐसी ऑटोमेटेड प्रोसेस से बचाते हैं जो Reports API का गलत तरीके से इस्तेमाल करती है. किसी एपीआई से बहुत ज़्यादा अनुरोध आने की वजह, टाइप करने में हुई कोई सामान्य गड़बड़ी हो सकती है. इसके अलावा, इसकी वजह ऐसा सिस्टम भी हो सकता है जिसे सही तरीके से डिज़ाइन नहीं किया गया है और जो बिना वजह एपीआई कॉल करता है. वजह चाहे जो भी हो, Google Workspace सिस्टम को बेहतर तरीके से काम करने के लिए, किसी सोर्स से आने वाले ट्रैफ़िक को एक तय सीमा तक पहुंचने के बाद ब्लॉक करना ज़रूरी है. इससे यह पक्का किया जाता है कि किसी डेवलपर की कार्रवाइयों से, बड़े समुदाय पर बुरा असर न पड़े.
अगर आपका एपीआई अनुरोध पूरा नहीं होता है, तो आपको एचटीटीपी स्टेटस कोड वाला जवाब मिलेगा. 403 स्टेटस कोड में, गलत इनपुट के बारे में गड़बड़ी की जानकारी होती है. साथ ही, 503 एचटीटीपी स्टेटस कोड में, गड़बड़ी की जानकारी होती है. इससे पता चलता है कि कौनसे एपीआई कोटा की सीमा पार हो गई है. इन जवाबों की मदद से, आपका कस्टम ऐप्लिकेशन इन गड़बड़ियों का पता लगा सकता है और ज़रूरी कार्रवाई कर सकता है.
अगर आपके अनुरोधों को तय समय में पूरा करना है, तो अपने अनुरोधों को एक साथ भेजें. इसके अलावा, अपने Java या C# ऐप्लिकेशन में कई थ्रेड का इस्तेमाल करें. एक साथ कई अनुरोध करने का उदाहरण यह है कि एक ही समय में, एक उपयोगकर्ता के कई ईमेल पते जोड़ने या हटाने के बजाय, अलग-अलग उपयोगकर्ताओं से ईमेल पतों के छोटे बैच का अनुरोध करना. थ्रेड के मामले में, 10 थ्रेड से शुरुआत करें. हर उपयोगकर्ता के ईमेल के लिए एक थ्रेड. ध्यान दें कि थ्रेड के सुझाव के कुछ फ़ायदे और कुछ नुकसान हैं. साथ ही, यह एपीआई से जुड़ी सभी स्थितियों के लिए फ़ायदेमंद नहीं है. अनुरोधों की संख्या बहुत ज़्यादा होने पर, कोटे से जुड़ी गड़बड़ियां दिखेंगी.
समय पर आधारित सभी गड़बड़ियों (हर थ्रेड के लिए N सेकंड में ज़्यादा से ज़्यादा N गड़बड़ियां) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले. साथ ही, 503 स्टेटस कोड वाली गड़बड़ियों के लिए, एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करके, कॉल को फिर से करने से पहले कुछ समय इंतज़ार करें. A Reports API example for one thread is to wait 5 seconds and retry the failed call. अगर अनुरोध पूरा हो जाता है, तो अन्य थ्रेड के लिए भी यही तरीका दोहराएं. अगर दूसरा अनुरोध पूरा नहीं होता है, तो आपके ऐप्लिकेशन को अनुरोध की फ़्रीक्वेंसी को तब तक कम करना चाहिए, जब तक कॉल पूरा न हो जाए. उदाहरण के लिए, शुरुआती पांच सेकंड के इंतज़ार के समय को बढ़ाकर 10 सेकंड करें. इसके बाद, कॉल करने की कोशिश फिर से करें. इसके अलावा, फिर से कोशिश करने की सीमा भी तय करें. उदाहरण के लिए, अपने ऐप्लिकेशन में उपयोगकर्ता को गड़बड़ी का मैसेज दिखाने से पहले, अनुरोध को पांच से सात बार फिर से भेजें. हर बार अनुरोध भेजने के बीच कुछ समय का अंतर रखें.
सीमाएं
| एपीआई की सीमाएं तय करने वाली कैटगरी | सीमाएं |
|---|---|
| QPS और QPD दरों की रिपोर्ट करना | यह एपीआई, आपके Google Cloud प्रोजेक्ट के लिए अनुरोधों की संख्या को सीमित करता है.
Google Cloud Console में सेट की गई डिफ़ॉल्ट वैल्यू, हर Google Cloud प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट 2,400 क्वेरी होती है. इस सीमा को अपने Google Cloud प्रोजेक्ट के Admin SDK API के कोटे वाले पेज से बढ़ाया जा सकता है.
अगर इन सीमाओं से ज़्यादा अनुरोध किए जाते हैं, तो सर्वर एचटीटीपी 503 स्टेटस कोड दिखाता है. अनुरोधों को फिर से आज़माते समय, एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करें. |
activities.list के लिए अन्य सीमाएं |
activities.list एपीआई के लिए, एक मिनट में फ़िल्टर की गई 250 क्वेरी (हर घंटे में फ़िल्टर की गई 15,000 क्वेरी) की अतिरिक्त सीमा तय की गई है. फ़िल्टर क्वेरी, एक ऐसा एपीआई अनुरोध होता है जिसमें कम से कम एक क्वेरी पैरामीटर शामिल होता है. ये क्वेरी पैरामीटर यहां दिए गए हैं:
|
| एपीआई कोटा की कैटगरी | कोटा |
| maxResults | एपीआई के जवाब के हर पेज में, 0 से 1,000 रिकॉर्ड तक दिखते हैं. डिफ़ॉल्ट रूप से, 1,000 रिकॉर्ड होते हैं. |
अन्य तरह की सीमाएं
| अन्य तरह की सीमाएं | सीमाएं और दिशा-निर्देश |
|---|---|
| डेटा फ़ॉर्मैट, डिफ़ॉल्ट | डेटा का डिफ़ॉल्ट फ़ॉर्मैट JSON होता है. यह एपीआई, ऐटम फ़ॉर्मैट के साथ भी काम करता है. |
| अनधिकृत अनुरोध | Google, एपीआई के लिए बिना अनुमति वाले अनुरोधों को स्वीकार नहीं करता. अगर अनुमति देने वाला टोकन नहीं दिया जाता है, तो अनुरोध को बिना अनुमति के किया गया अनुरोध माना जाता है. ज़्यादा जानकारी के लिए, अनुरोधों को अनुमति देना लेख पढ़ें. |
| चेतावनी वाले मैसेज |
|
activities.list के लिए सबसे सही तरीके
ऑडिट की जांच के लिए, activities.list तरीके का इस्तेमाल किया जाना चाहिए. बेहतरीन परफ़ॉर्मेंस के लिए, आपके अनुरोध में startTime और endTime पैरामीटर का इस्तेमाल करके, समयसीमा शामिल होनी चाहिए. समय की छोटी रेंज से, जवाब देने में लगने वाला समय काफ़ी कम हो जाता है. इस तरीके का इस्तेमाल, ऑडिट लॉग को बड़ी संख्या में वापस पाने के लिए नहीं किया जाता. अगर आप activities.list फ़िल्टर के अनुरोध के कोटे का नियमित तौर पर इस्तेमाल कर रहे हैं, तो यहां दिए गए विकल्पों पर विचार करें:
- Google Workspace के लॉग को BigQuery में एक्सपोर्ट करने की सुविधा सेट अप करें. साथ ही, BigQuery के क्वेरी एपीआई का इस्तेमाल करके, अपनी ज़रूरत का डेटा पाएं और उसका विश्लेषण करें. इसके लिए, आपको एपीआई कोटा की कोई पाबंदी नहीं झेलनी पड़ेगी.
- फ़िल्टर किए गए अनुरोधों का इस्तेमाल करने के बजाय, समयसीमा के साथ फ़िल्टर नहीं किए गए अनुरोधों का इस्तेमाल करें.साथ ही, क्लाइंट-साइड फ़िल्टरिंग करें. इसका मतलब है कि अपने ऐप्लिकेशन में फ़िल्टरिंग लॉजिक लागू करें. इससे आपको हर मिनट 250 फ़िल्टर क्वेरी की सीमा से ज़्यादा क्वेरी करने की सुविधा मिलती है. हालांकि, Google Cloud प्रोजेक्ट के लिए, हर उपयोगकर्ता को हर मिनट 2,400 क्वेरी करने की सीमा का पालन करना होगा.