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