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