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