सीमाएं और कोटा

सीमाएं और कोटा, Google के इन्फ़्रास्ट्रक्चर को ऐसी ऑटोमेटेड प्रोसेस से बचाते हैं जो Reports API का गलत तरीके से इस्तेमाल करती है. किसी एपीआई से बहुत ज़्यादा अनुरोध, टाइप करने में हुई किसी सामान्य गड़बड़ी की वजह से हो सकते हैं. इसके अलावा, यह भी हो सकता है कि सिस्टम को सही तरीके से डिज़ाइन न किया गया हो. इस वजह से, वह एपीआई को गैर-ज़रूरी कॉल करता हो. वजह चाहे जो भी हो, Google Workspace सिस्टम को बेहतर तरीके से काम करने के लिए, किसी सोर्स से आने वाले ट्रैफ़िक को एक तय सीमा तक पहुंचने के बाद ब्लॉक करना ज़रूरी है. इससे यह पक्का होता है कि किसी डेवलपर की कार्रवाइयों से, बड़े समुदाय पर बुरा असर नहीं पड़ सकता.

अगर आपका एपीआई अनुरोध पूरा नहीं होता है, तो आपको एचटीटीपी स्टेटस कोड का जवाब मिलेगा. 403 स्टेटस कोड में, गलत इनपुट के बारे में गड़बड़ी की जानकारी होती है. साथ ही, 503 एचटीटीपी स्टेटस कोड में, गड़बड़ी की जानकारी होती है. इससे पता चलता है कि कौनसे एपीआई कोटा की सीमा पार हो गई है. इन जवाबों की मदद से, आपका कस्टम ऐप्लिकेशन इन गड़बड़ियों का पता लगा सकता है और ज़रूरी कार्रवाई कर सकता है.

अगर आपके अनुरोधों को तय समय में पूरा करना है, तो अपने अनुरोधों को एक साथ भेजें. इसके अलावा, अपने Java या C# ऐप्लिकेशन में एक से ज़्यादा थ्रेड का इस्तेमाल करें. एक साथ कई अनुरोध करने का एक उदाहरण यह है कि एक उपयोगकर्ता के कई ईमेल पते जोड़ने या हटाने के बजाय, अलग-अलग उपयोगकर्ताओं से ईमेल पतों के छोटे बैच का अनुरोध करना. थ्रेड के मामले में, हर उपयोगकर्ता के ईमेल के लिए एक थ्रेड का इस्तेमाल करके, 10 थ्रेड से शुरुआत करें. ध्यान दें कि थ्रेड के सुझाव के कुछ फ़ायदे और कुछ नुकसान हैं. साथ ही, यह एपीआई से जुड़ी सभी स्थितियों के लिए फ़ायदेमंद नहीं है. अनुरोधों की संख्या बहुत ज़्यादा होने पर, कोटे से जुड़ी गड़बड़ियां होंगी.

समय पर आधारित सभी गड़बड़ियों (हर थ्रेड के लिए N सेकंड में ज़्यादा से ज़्यादा N गड़बड़ियां) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले. साथ ही, एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करके, कॉल को फिर से आज़माने से पहले कुछ समय तक इंतज़ार करे. खास तौर पर, 503 स्टेटस कोड वाली गड़बड़ियों के लिए ऐसा करें. एक थ्रेड के लिए Reports API का उदाहरण यह है कि पांच सेकंड तक इंतज़ार करें और पूरे न हो पाने वाले कॉल को फिर से आज़माएं. अगर अनुरोध पूरा हो जाता है, तो अन्य थ्रेड के लिए भी इसी पैटर्न को दोहराएं. अगर दूसरा अनुरोध पूरा नहीं होता है, तो आपका ऐप्लिकेशन अनुरोध की फ़्रीक्वेंसी को तब तक कम करता रहेगा, जब तक कॉल पूरा नहीं हो जाता. उदाहरण के लिए, कॉल शुरू होने में लगने वाले शुरुआती पांच सेकंड के समय को बढ़ाकर 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 क्वेरी) की अतिरिक्त सीमा होती है. फ़िल्टर क्वेरी, एक एपीआई अनुरोध होता है. इसमें कम से कम एक क्वेरी पैरामीटर शामिल होता है:
  • userKey
  • actorIpAddress
  • eventName
  • filters
  • orgUnitID
  • groupIdFilter
एपीआई कोटा की कैटगरी कोटा
maxResults एपीआई के जवाब के हर पेज में, 0 से 1,000 रिकॉर्ड तक दिखते हैं. डिफ़ॉल्ट रूप से, 1,000 रिकॉर्ड होते हैं.

अन्य तरह की सीमाएं

अन्य तरह की सीमाएं सीमाएं और दिशा-निर्देश
डेटा फ़ॉर्मैट, डिफ़ॉल्ट डेटा का डिफ़ॉल्ट फ़ॉर्मैट JSON होता है. यह एपीआई, ऐटम फ़ॉर्मैट के साथ भी काम करता है.
बिना अनुमति के किए गए अनुरोध Google, एपीआई के लिए बिना अनुमति वाले अनुरोधों को स्वीकार नहीं करता. अगर अनुमति देने वाला टोकन नहीं दिया जाता है, तो अनुरोध को बिना अनुमति के किया गया अनुरोध माना जाता है. ज़्यादा जानकारी के लिए, अनुरोधों को अनुमति देना लेख पढ़ें.
चेतावनी वाले मैसेज
  • डेटा उपलब्ध नहीं है: इस ऐप्लिकेशन और इस तारीख का डेटा उपलब्ध नहीं है. साथ ही, यह आने वाले समय में भी उपलब्ध नहीं होगा.
  • डेटा का कुछ हिस्सा उपलब्ध है: इस ऐप्लिकेशन और इस तारीख का डेटा, आने वाले समय में उपलब्ध हो सकता है.
Reports API के चेतावनी सिंटैक्स के लिए, customers और users के लिए एपीआई का रेफ़रंस देखें.

activities.list के लिए सबसे सही तरीके

ऑडिट की जांच के लिए, activities.list तरीके का इस्तेमाल किया जाना चाहिए. बेहतरीन परफ़ॉर्मेंस के लिए, startTime और endTime पैरामीटर का इस्तेमाल करके, अनुरोध में समयसीमा शामिल करें. समयसीमा कम होने पर, जवाब मिलने में लगने वाला समय काफ़ी कम हो जाता है. इस तरीके का इस्तेमाल, ऑडिट लॉग को बड़ी संख्या में वापस पाने के लिए नहीं किया जाता. अगर आप activities.list फ़िल्टर के अनुरोध के कोटे का लगातार इस्तेमाल कर रहे हैं, तो यहां दिए गए विकल्प आज़माएं:

  • Google Workspace के लॉग को BigQuery में एक्सपोर्ट करने की सुविधा सेट अप करें. साथ ही, BigQuery के बेहतर क्वेरी एपीआई का इस्तेमाल करके, अपनी ज़रूरत का डेटा पाएं और उसका विश्लेषण करें. इसके लिए, एपीआई के कोटे की कोई पाबंदी नहीं होगी.
  • फ़िल्टर किए गए अनुरोधों के बजाय, समयसीमा के साथ फ़िल्टर नहीं किए गए अनुरोधों का इस्तेमाल करें.साथ ही, क्लाइंट-साइड फ़िल्टरिंग करें. इसका मतलब है कि अपने ऐप्लिकेशन में फ़िल्टरिंग लॉजिक लागू करें. इससे आपको हर मिनट में 250 फ़िल्टर क्वेरी की सीमा से ज़्यादा क्वेरी करने की सुविधा मिलती है. हालांकि, हर उपयोगकर्ता के लिए, हर मिनट में 2,400 क्वेरी करने की सीमा अब भी लागू रहेगी. यह सीमा, हर Google Cloud प्रोजेक्ट के लिए लागू होती है.