फ़िलहाल, हम रिपोर्ट टाइप के सबसेट को ऑफ़लाइन से झटपट रिपोर्टिंग में माइग्रेट कर रहे हैं. उपयोगकर्ता के माइग्रेट हो जाने के बाद, queries.list जवाबों में मौजूदा इंस्टैंट रिपोर्ट शामिल होंगी. ज़्यादा जानकारी के लिए, हमारी ब्लॉग पोस्ट देखें.
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
कोटा, Google के इंफ़्रास्ट्रक्चर को ऐसी ऑटोमेटेड प्रोसेस से बचाते हैं जो Google बिड मैनेजर एपीआई का गलत तरीके से इस्तेमाल करती हैं. वे यह पक्का करते हैं कि किसी डेवलपर की कार्रवाई की वजह से, पूरी कम्यूनिटी पर बुरा असर न पड़े.
कोटे की सीमाएं
नीचे दी गई डिफ़ॉल्ट कोटा सीमाएं, सभी बोली मैनेजर एपीआई संसाधनों और तरीकों से शेयर की जाती हैं.
हर प्रोजेक्ट के लिए चार क्वेरी प्रति सेकंड (क्यूपीएस).
Google API कंसोल में इस कोटा को प्रति मिनट क्वेरी के तौर पर जाना जाता है. इसे 240 पर सेट किया जाता है.
स्टोरेज कोटा पार हो गई है
अगर कोटे की तय सीमा को पार करने की वजह से आपका अनुरोध फ़ेल हो जाता है, तो एपीआई एक एचटीटीपी स्टेटस कोड और गड़बड़ी की वजह दिखाता है. इसके अलावा, जवाब के मुख्य हिस्से में गड़बड़ी की वजह का पूरा ब्यौरा होता है. गड़बड़ी के जवाब के उदाहरण के लिए, गड़बड़ी के मैसेज गाइड देखें.
इस सूची में संभावित गड़बड़ियों की जानकारी दी गई है. साथ ही, कोटा की सीमाओं को पार करने की वजह से पूरे न हो पाने के लिए, सुझाई गई कार्रवाइयों के सुझाव दिए गए हैं.
कोड
वजह
मैसेज
सुझाई गई कार्रवाई
403
dailyLimitExceeded
रोज़ाना इस्तेमाल की सीमा पूरी हो चुकी है
समस्या को ठीक किए बिना फिर से कोशिश न करें. Google API (एपीआई) कंसोल में अपने इस्तेमाल की जांच करें और कम अनुरोध करने के लिए अपने वर्कफ़्लो में बदलाव करें. अगर आपको लगता है कि इस्तेमाल करना सही है, तो अतिरिक्त कोटा का अनुरोध किया जा सकता है.
एक्सपोनेन्शियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ियों को मैनेज करने की स्टैंडर्ड रणनीति है. इसमें क्लाइंट समय-समय पर, अनुरोध न कर पाने की कोशिश को बार-बार करता रहता है. अगर अनुरोधों की ज़्यादा संख्या या ज़्यादा नेटवर्क ट्रैफ़िक की वजह से सर्वर, गड़बड़ियां दिखाता है, तो एक्स्पोनेंशियल बैकऑफ़, उन गड़बड़ियों को ठीक करने का एक अच्छा तरीका हो सकता है. इसके उलट, यह नेटवर्क वॉल्यूम या जवाब मिलने में लगने वाले समय से जुड़ी गड़बड़ियों को ठीक करने के लिए काम की रणनीति नहीं है. जैसे, पुष्टि करने के अमान्य क्रेडेंशियल या फ़ाइल नहीं मिलने की गड़बड़ियां.
एक्स्पोनेंशियल बैकऑफ़ सुविधा का इस्तेमाल सही तरीके से किया जाए, तो इसका इस्तेमाल करने से बैंडविथ के इस्तेमाल की क्षमता बढ़ जाती है और कामयाब रिस्पॉन्स पाने के लिए अनुरोधों की संख्या कम हो जाती है. साथ ही, यह एक साथ काम करने वाली जगहों पर अनुरोधों की संख्या को बढ़ाता है.
सिंपल एक्सपोनेन्शियल बैकऑफ़ लागू करने का फ़्लो इस तरह है:
एपीआई से अनुरोध करें.
HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
1 सेकंड + random_number_मिलीसेकंड तक इंतज़ार करें और फिर से कोशिश करें.
HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
दो सेकंड + random_number_मिलीसेकंड तक इंतज़ार करें और फिर से कोशिश करें.
HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
4 सेकंड रैंडम नंबर_मिलीसेकंड तक इंतज़ार करें और फिर से कोशिश करें.
HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
आठ सेकंड से ज़्यादा समय तक किसी भी समय इंतज़ार करें और फिर से कोशिश करें.
HTTP 503 जवाब पाएं. इससे पता चलता है कि आपको फिर से अनुरोध करने की कोशिश करनी चाहिए.
16 सेकंड + यादृच्छिक_number_मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
वीडियो बंद करने के लिए. किसी गड़बड़ी की रिपोर्ट करें या उसे लॉग करें.
ऊपर दिए गए फ़्लो में, random_number_मिलीसेकंड, 1,000 या उससे कम या उसके बराबर मिलीसेकंड की कोई रैंडम संख्या है. ऐसा करना ज़रूरी है, क्योंकि थोड़ी सी भी देरी शुरू करने से, लोड को ज़्यादा समान तरीके से बांटने में मदद मिलती है. साथ ही, सर्वर पर स्टैंप लगाए जाने की संभावना से बचा जा सकता है. हर इंतज़ार के बाद, रैंडम नंबर_मिलीसेकंड की वैल्यू फिर से तय करनी चाहिए.
ध्यान दें: इंतज़ार हमेशा (2 ^ n) + random_number_मिलीसेकंड होता है, जहां n एक तरह से बढ़ने वाला पूर्णांक होता है. शुरुआत में इसकी वैल्यू 0 से तय होती है. हर इटरेशन (हर अनुरोध) के लिए, पूर्णांक n में 1 की बढ़ोतरी होती है.
n 5 के होने पर एल्गोरिदम खत्म हो जाता है. यह सीलिंग क्लाइंट को दोबारा कोशिश करने से रोकती है. इसकी वजह से, किसी अनुरोध को "ठीक न की जा सकने वाली गड़बड़ी" माना जाने से पहले, करीब 32 सेकंड की देरी हो जाती है. ज़्यादा से ज़्यादा संख्या में बार-बार कोशिश करने से कोई परेशानी नहीं होती. खास तौर पर तब, जब वीडियो अपलोड करने की एक लंबी प्रोसेस चल रही हो. बस कोशिश करें कि दोबारा कोशिश करने के लिए एक मिनट से कम समय दें.
हर दिन के लिए अतिरिक्त कोटा का अनुरोध किया जा रहा है
अगर आपको लगता है कि आपके आवेदन के लिए हर दिन अतिरिक्त कोटा चाहिए, तो नीचे दिए गए निर्देशों का पालन करके ज़्यादा अनुरोध किए जा सकते हैं.
नीचे दिए गए निर्देश, सिर्फ़ उन प्रोजेक्ट पर लागू होते हैं जिनमें dailyLimitExceeded की गड़बड़ी हुई है. कोटा की अन्य गड़बड़ियों के लिए सुझाई गई कार्रवाइयां, ऊपर दी गई टेबल में दी गई हैं.
मेट्रिक पेज पर, इस्तेमाल के आंकड़ों की समीक्षा करें और पक्का करें कि आपका ऐप्लिकेशन उम्मीद के मुताबिक काम कर रहा हो. आगे बढ़ने से पहले, कॉल किए गए तरीकों पर ध्यान दें और अचानक या ज़रूरत से ज़्यादा इस्तेमाल हुए तरीकों को ठीक करें.
अगर इस्तेमाल सामान्य है, तो कोटा पेज पर जाएं. इसके बाद, हर दिन की क्वेरी के बगल में 'बदलाव करें' आइकॉन पर क्लिक करें और "ज़्यादा कोटा के लिए आवेदन करें" वाले लिंक पर क्लिक करें.
बढ़ोतरी का अनुरोध सबमिट करने से पहले, जानकारी को अच्छी तरह से पढ़ लें और कोटा अनुरोध फ़ॉर्म में शामिल निर्देशों का पालन करें.
[[["समझने में आसान है","easyToUnderstand","thumb-up"],["मेरी समस्या हल हो गई","solvedMyProblem","thumb-up"],["अन्य","otherUp","thumb-up"]],[["वह जानकारी मौजूद नहीं है जो मुझे चाहिए","missingTheInformationINeed","thumb-down"],["बहुत मुश्किल है / बहुत सारे चरण हैं","tooComplicatedTooManySteps","thumb-down"],["पुराना","outOfDate","thumb-down"],["अनुवाद से जुड़ी समस्या","translationIssue","thumb-down"],["सैंपल / कोड से जुड़ी समस्या","samplesCodeIssue","thumb-down"],["अन्य","otherDown","thumb-down"]],["आखिरी बार 2024-08-22 (UTC) को अपडेट किया गया."],[],[]]
