रेट लिमिट
Google Ads API, हर क्लाइंट ग्राहक आईडी (सीआईडी) और डेवलपर टोकन, दोनों के हिसाब से क्वेरी प्रति सेकंड (क्यूपीएस) के हिसाब से रेट को सीमित करने के अनुरोधों का बकेट करता है. इसका मतलब है कि मीटरिंग को सीआईडी और डेवलपर टोकन, दोनों पर अलग से लागू किया जाता है. Google Ads API मीटर अनुरोधों के लिए टोकन बकेट एल्गोरिदम का इस्तेमाल करता है और सही क्यूपीएस सीमा तय करता है. इसलिए, किसी एक समय में पूरे सर्वर लोड के आधार पर सटीक सीमा अलग-अलग होगी.
दरों को लागू करने का मकसद यह है कि एक उपयोगकर्ता को, Google Ads API के सर्वर पर बड़ी संख्या में अनुरोध करके, दूसरे उपयोगकर्ताओं की सेवा में रुकावट डालने से रोका जा सके. ऐसा जान-बूझकर या अनजाने में किया जा सकता है.
रेट लिमिट का उल्लंघन करने वाले अनुरोध, इस गड़बड़ी के साथ अस्वीकार कर दिए जाएंगे:
RESOURCE_TEMPORARILY_EXHAUSTED.
क्लाइंट-साइड से अनुरोधों की संख्या और क्यूपीएस को कम करके, अपने ऐप्लिकेशन को कंट्रोल किया जा सकता है और रेट की सीमाओं को कम किया जा सकता है.
दर सीमा पार हो जाने की संभावना को कम करने के कई तरीके हैं. एंटरप्राइज़ इंटिग्रेशन पैटर्न (ईआईपी) के कॉन्सेप्ट, जैसे कि मैसेज सेवा, री डिलीवरी, और थ्रॉटलिंग के बारे में जानकर, आपको ज़्यादा मज़बूत क्लाइंट ऐप्लिकेशन बनाने में मदद मिल सकती है.
नीचे दिए गए सुझावों को जटिलता के हिसाब से व्यवस्थित किया गया है. इनमें सबसे आसान रणनीतियों को प्राथमिकता दी गई है और बाद में इन तरीकों को ज़्यादा मज़बूत, लेकिन खास बनाया गया है:
- एक साथ होने वाले टास्क की संख्या सीमित करना
- एक साथ कई अनुरोध करने की सुविधा
- थ्रॉटलिंग और रेट लिमिटर
- सूची बनाना
एक साथ कम समय में किए जाने वाले टास्क सीमित करें
रेट की सीमाओं से ज़्यादा काम करने की एक मुख्य वजह यह है कि क्लाइंट ऐप्लिकेशन से, साथ-साथ काम करने के लिए बहुत ज़्यादा संख्या में टास्क मिल रहे हैं. हालांकि, हम किसी क्लाइंट ऐप्लिकेशन के साथ-साथ चलने वाले अनुरोधों की संख्या को सीमित नहीं करते. हालांकि, डेवलपर टोकन के लेवल पर, इससे हर सेकंड के अनुरोधों की सीमा को पार करना पड़ सकता है.
हमारा सुझाव है कि सभी प्रोसेस और मशीनों से किए जाने वाले टास्क की कुल संख्या के लिए, एक उचित ऊपरी सीमा सेट करें. साथ ही, अनुरोध करने की दर को तय करने की सीमा को पार किए बिना, अपनी साइट के थ्रूपुट को ऑप्टिमाइज़ करने के लिए, ऊपर की ओर अडजस्ट करने का सुझाव दिया जाता है.
इसके अलावा, आपके पास क्लाइंट साइड से क्यूपीएस को थ्रॉटल करने का विकल्प है. थ्रॉटलिंग और रेट लिमिटर देखें.
एक साथ ग्रुप बनाने के अनुरोध
कई ऑपरेशन को एक ही अनुरोध में शामिल करने के बारे में सोचें. ऐसा MutateFoo कॉल
के लिए सबसे ज़्यादा किया जाता है. उदाहरण के लिए, अगर AdGroupAd के एक से ज़्यादा इंस्टेंस के लिए स्टेटस अपडेट किया जा रहा है - तो हर AdGroupAd के लिए MutateAdGroupAds को एक बार कॉल करने के बजाय, MutateAdGroupAds को एक बार कॉल किया जा सकता है. साथ ही, एक से ज़्यादा operations कोड पास किए जा सकते हैं. कुछ और उदाहरणों के लिए, बैच से जुड़ी कार्रवाइयों के लिए दिशा-निर्देश देखें.
अनुरोध एक साथ भेजने से, अनुरोधों की कुल संख्या कम हो जाती है और अनुरोध प्रति मिनट की सीमा कम हो जाती है. हालांकि, अगर एक ही खाते पर बहुत ज़्यादा कार्रवाइयां की जाती हैं, तो हर मिनट के हिसाब से अनुरोध करने की दर की सीमा लागू हो सकती है.
थ्रॉटलिंग और रेट लिमिटर
अपने क्लाइंट ऐप्लिकेशन में थ्रेड की कुल संख्या को सीमित करने के अलावा, क्लाइंट साइड पर भी रेट लिमिटर लागू किए जा सकते हैं. इससे यह पक्का हो सकता है कि आपकी सभी प्रोसेस और / या क्लस्टर में मौजूद सभी थ्रेड, क्लाइंट साइड की खास क्यूपीएस सीमा से नियंत्रित हों.
आपके पास Guava Rate लिमिटर को देखने का विकल्प है या क्लस्टर किए गए एनवायरमेंट के लिए, अपने टोकन बकेट वाले एल्गोरिदम को लागू करने का विकल्प है. उदाहरण के लिए, टोकन जनरेट किए जा सकते हैं और उन्हें डेटाबेस जैसे शेयर किए गए ट्रांज़ैक्शन स्टोरेज में सेव किया जा सकता है. साथ ही, अनुरोध को प्रोसेस करने से पहले, हर क्लाइंट को टोकन हासिल करके उसका इस्तेमाल करना होगा. अगर टोकन इस्तेमाल कर लिए गए हैं, तो क्लाइंट को टोकन का अगला बैच जनरेट होने तक इंतज़ार करना होगा.
सूची बनाने की सुविधा
मैसेज सूची की मदद से, ऑपरेशन लोड के डिस्ट्रिब्यूशन के साथ-साथ अनुरोध और उपभोक्ता दरों को भी कंट्रोल किया जा सकता है. मैसेज की सूची के कई विकल्प उपलब्ध हैं. इनमें से कुछ ओपन सोर्स और मालिकाना हक वाले हैं. इनमें से कई विकल्प अलग-अलग भाषाओं में काम कर सकते हैं.
मैसेज की सूची का इस्तेमाल करते समय, आपके पास एक से ज़्यादा प्रोड्यूसर हो सकते हैं जो मैसेज को सूची में भेज रहे हों और कई उपभोक्ता उन मैसेज को प्रोसेस कर रहे हों. उपभोक्ताओं के लिए, थ्रॉटल की सुविधा एक साथ लागू की जा सकती है. इसके लिए, एक साथ इस्तेमाल किए जाने वाले उपभोक्ताओं की संख्या को सीमित किया जा सकता है. इसके अलावा, मैन्युफ़ैक्चरर या उपभोक्ताओं के लिए रेट लिमिटर या थ्रॉटलर लागू किए जा सकते हैं.
उदाहरण के लिए, अगर किसी मैसेज उपभोक्ता के सामने किराया तय करने की सीमा की गड़बड़ी दिखती है, तो वह उपभोक्ता फिर से अनुरोध करने के लिए उसे सूची में भेज सकता है. इसी दौरान, उपभोक्ता दूसरे सभी उपभोक्ताओं को भी यह सूचना दे सकता है कि वे इस गड़बड़ी को ठीक करने के लिए, प्रोसेस को कई सेकंड तक रोक दें.