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