आरटीबी ऐप्लिकेशन के लिए सबसे सही तरीके

इस गाइड में, आरटीबी प्रोटोकॉल के मुताबिक ऐप्लिकेशन डेवलप करते समय ध्यान में रखने के सबसे सही तरीकों के बारे में बताया गया है.

कनेक्शन मैनेज करना

कनेक्शन बनाए रखना

नया कनेक्शन बनाने पर, इंतज़ार का समय बढ़ जाता है. साथ ही, मौजूदा कनेक्शन का फिर से इस्तेमाल करने के मुकाबले, दोनों तरफ़ ज़्यादा संसाधनों की ज़रूरत पड़ती है. कम कनेक्शन बंद करके, उन कनेक्शन की संख्या कम की जा सकती है जिन्हें फिर से खोलना होगा.

पहला, हर नए कनेक्शन को सेट अप करने के लिए, नेटवर्क के एक और राउंड-ट्रिप की ज़रूरत होती है. हम मांग पर कनेक्शन बनाते हैं. इसलिए, किसी कनेक्शन के लिए किए गए पहले अनुरोध की समयसीमा कम होती है. साथ ही, बाद के अनुरोधों की तुलना में, इस अनुरोध के टाइम आउट होने की संभावना ज़्यादा होती है. ज़्यादा टाइम आउट होने पर, गड़बड़ी की दर बढ़ जाती है. इससे बिडिंग करने वाले आपके सिस्टम को कम से कम बिडिंग करने के लिए कहा जा सकता है.

दूसरा, कई वेब सर्वर, हर सेट अप किए गए कनेक्शन के लिए एक खास वर्क थ्रेड बनाते हैं. इसका मतलब है कि कनेक्शन को बंद करने और फिर से बनाने के लिए, सर्वर को एक थ्रेड को बंद करके खारिज करना होगा, एक नई थ्रेड को असाइन करना होगा, उसे चलाने लायक बनाना होगा, और आखिर में अनुरोध को प्रोसेस करने से पहले, कनेक्शन की स्थिति बनानी होगी. यह बहुत ज़्यादा और ग़ैर-ज़रूरी है.

कनेक्शन बंद होने से बचना

कनेक्शन के व्यवहार को ट्यून करके शुरुआत करें. ज़्यादातर सर्वर डिफ़ॉल्ट तौर पर, ऐसे एनवायरमेंट के लिए बनाए जाते हैं जिनमें बड़ी संख्या में क्लाइंट होते हैं और हर क्लाइंट कुछ ही अनुरोध करता है. इसके उलट, आरटीबी के लिए, मशीनों का एक छोटा पूल, बड़ी संख्या में ब्राउज़र की ओर से अनुरोध भेजता है. इन स्थितियों में, कनेक्शन का ज़्यादा से ज़्यादा बार इस्तेमाल करना सही रहता है. हमारा सुझाव है कि आप ये सेट करें:

• डिवाइस को इस्तेमाल में न होने पर, उसे 2.5 मिनट के बाद 'इस्तेमाल में नहीं है' माना जाएगा.
• किसी कनेक्शन पर अनुरोधों की ज़्यादा से ज़्यादा संख्या, जो सबसे ज़्यादा वैल्यू हो सकती है.
• ज़्यादा से ज़्यादा कनेक्शन की संख्या, आपके रैम में सेव किए जा सकने वाले डेटा की वैल्यू के हिसाब से होनी चाहिए. साथ ही, यह भी पक्का करें कि कनेक्शन की संख्या, रैम में सेव किए जा सकने वाले डेटा की वैल्यू के आस-पास न हो.

उदाहरण के लिए, Apache में, KeepAliveTimeout को 150, MaxKeepAliveRequests को शून्य, और MaxClients को ऐसी वैल्यू पर सेट करना होगा जो सर्वर टाइप पर निर्भर करती है.

कनेक्शन के व्यवहार को ट्यून करने के बाद, आपको यह भी पक्का करना चाहिए कि आपका बिडर कोड, ज़रूरत के बिना कनेक्शन बंद न करे. उदाहरण के लिए, अगर आपके पास ऐसा फ़्रंट-एंड कोड है जो बैकएंड में गड़बड़ी या टाइम आउट होने पर, डिफ़ॉल्ट रूप से "बिड नहीं" रिस्पॉन्स दिखाता है, तो पक्का करें कि कोड, कनेक्शन बंद किए बिना अपना रिस्पॉन्स दिखाता हो. इससे, बिडिंग सिस्टम के ओवरलोड होने, कनेक्शन बंद होने, और टाइम आउट की संख्या बढ़ने की स्थिति से बचा जा सकता है. इन वजहों से, बिडिंग सिस्टम को कम से कम इस्तेमाल किया जाता है.

कनेक्टिविटी को संतुलित रखना

अगर Authorized Buyers, प्रॉक्सी सर्वर के ज़रिए आपके बिडर के सर्वर से कनेक्ट होता है, तो समय के साथ कनेक्शन असंतुलित हो सकते हैं. ऐसा इसलिए, क्योंकि Authorized Buyers को सिर्फ़ प्रॉक्सी सर्वर का आईपी पता पता होता है. इसलिए, यह तय नहीं किया जा सकता कि हर कॉलआउट किस बिडर सर्वर को मिल रहा है. समय के साथ, अनुमति पा चुके खरीदार कनेक्शन बनाते और बंद करते हैं. साथ ही, बिडर के सर्वर फिर से शुरू होते हैं. इस वजह से, हर कनेक्शन के लिए मैप किए गए कनेक्शन की संख्या काफ़ी अलग-अलग हो सकती है.

जब कुछ कनेक्शन का ज़्यादा इस्तेमाल किया जाता है, तो हो सकता है कि खोले गए अन्य कनेक्शन ज़्यादातर समय के लिए बंद रहें. ऐसा इसलिए होता है, क्योंकि उस समय उनकी ज़रूरत नहीं होती. अनुमति पा चुके खरीदारों के ट्रैफ़िक में बदलाव होने पर, निष्क्रिय कनेक्शन चालू हो सकते हैं और चालू कनेक्शन निष्क्रिय हो सकते हैं. अगर कनेक्शन को खराब तरीके से क्लस्टर किया जाता है, तो इनकी वजह से बिडर सर्वर पर असमान लोड पड़ सकता है. Google, 10,000 अनुरोधों के बाद सभी कनेक्शन बंद करके, इस समस्या को रोकने की कोशिश करता है. इससे, समय के साथ लोकप्रिय कनेक्शन अपने-आप फिर से बैलेंस हो जाते हैं. अगर आपको अब भी अपने एनवायरमेंट में ट्रैफ़िक का असंतुलन दिखता है, तो ये कार्रवाइयां की जा सकती हैं:

1. अगर फ़्रंटएंड प्रॉक्सी का इस्तेमाल किया जा रहा है, तो हर कनेक्शन के लिए एक बार के बजाय हर अनुरोध के लिए बैकएंड चुनें.
2. अगर किसी हार्डवेयर लोड बैलेंसर या फ़ायरवॉल के ज़रिए कनेक्शन को प्रॉक्सी किया जा रहा है और कनेक्शन बन जाने के बाद मैपिंग तय हो जाती है, तो हर कनेक्शन के लिए अनुरोधों की ज़्यादा से ज़्यादा संख्या तय करें. ध्यान दें कि Google ने पहले से ही हर कनेक्शन के लिए 10,000 अनुरोधों की ऊपरी सीमा तय की है. इसलिए, अगर आपको अब भी अपने एनवायरमेंट में हॉट कनेक्शन क्लस्टर होते दिखते हैं, तो आपको ज़्यादा सख्त वैल्यू देनी होगी. उदाहरण के लिए, Apache में, MaxKeepAliveRequests को 5,000 पर सेट करें
3. बिडर के सर्वर को कॉन्फ़िगर करके, उनके अनुरोध की दरों पर नज़र रखें. साथ ही, अगर वे अपने साथियों की तुलना में लगातार बहुत ज़्यादा अनुरोध हैंडल कर रहे हैं, तो अपने कुछ कनेक्शन बंद करें.

ओवरलोड को आसानी से मैनेज करना

आम तौर पर, कोटा ज़्यादा सेट किए जाते हैं, ताकि बिडिंग की सुविधा देने वाली आपकी कंपनी को वे सभी अनुरोध मिल सकें जिन्हें वह मैनेज कर सकती है. हालांकि, इससे ज़्यादा अनुरोध नहीं मिलते. असल में, कोटा को सबसे सही लेवल पर रखना मुश्किल होता है. साथ ही, कई वजहों से ओवरलोड भी होता है. जैसे, व्यस्त समय के दौरान बैकएंड का बंद होना, ट्रैफ़िक मिक्स में बदलाव होना, ताकि हर अनुरोध के लिए ज़्यादा प्रोसेसिंग की ज़रूरत पड़े या कोटा की वैल्यू बहुत ज़्यादा सेट की गई हो. इसलिए, यह सोचना ज़रूरी है कि बहुत ज़्यादा ट्रैफ़िक आने पर, बिडिंग की आपकी रणनीति कैसा परफ़ॉर्म करेगी.

क्षेत्रों (खास तौर पर, एशिया और अमेरिका के पश्चिमी और पूर्वी हिस्सों के बीच) के बीच ट्रैफ़िक में होने वाले अस्थायी बदलावों (एक हफ़्ते तक) को ध्यान में रखते हुए, हमारा सुझाव है कि आप हर ट्रेडिंग लोकेशन के लिए, सात दिनों के पीक और क्यूपीएस के बीच 15% का अंतर रखें.

ज़्यादा लोड के दौरान के व्यवहार के हिसाब से, बिडर तीन मुख्य कैटगरी में आते हैं:

"सभी बिड पर जवाब देने वाला" बिडर

इसे लागू करना आसान है, लेकिन ज़्यादा लोड होने पर यह बिडिंग सिस्टम सबसे खराब परफ़ॉर्म करता है. यह हर बिड रिक्वेस्ट का जवाब देने की कोशिश करता है. भले ही, वह रिक्वेस्ट किसी भी तरह का हो. साथ ही, जो रिक्वेस्ट तुरंत नहीं दिए जा सकते उन्हें सूची में जोड़ देता है. आम तौर पर, ऐसा करने पर यह स्थिति बनती है:

• अनुरोध की दर बढ़ने पर, अनुरोधों को पूरा होने में लगने वाला समय भी बढ़ जाता है. ऐसा तब तक होता है, जब तक सभी अनुरोधों के लिए समयसीमा खत्म नहीं हो जाती
• कॉलआउट रेट के पीक पर पहुंचने पर, इंतज़ार का समय काफ़ी बढ़ जाता है
• थ्रॉटल करने की सुविधा चालू हो जाती है, जिससे अनुमति वाले कॉलआउट की संख्या काफ़ी कम हो जाती है
• इंतज़ार का समय कम होने लगता है, जिसकी वजह से ट्रॉथलिंग कम हो जाती है
• इसके बाद, साइकल फिर से शुरू हो जाता है.

इस बिडर के लिए इंतज़ार का ग्राफ़, बहुत ज़्यादा तीव्र आकार के दांतों वाले पैटर्न जैसा दिखता है. इसके अलावा, सूची में शामिल अनुरोधों की वजह से, सर्वर को मेमोरी पेजिंग शुरू करनी पड़ती है या ऐसा कुछ और करना पड़ता है जिससे लंबे समय तक सर्वर धीमा हो जाता है. साथ ही, अनुरोधों को पूरा होने में लगने वाला समय, व्यस्त समय खत्म होने तक कम नहीं होता. इस वजह से, व्यस्त समय के दौरान कॉलआउट रेट कम हो जाते हैं. दोनों ही मामलों में, कोटा को कम वैल्यू पर सेट करने के मुकाबले कम कॉलआउट किए जाते हैं या उनका जवाब दिया जाता है.

"ओवरलोड होने पर गड़बड़ी" बिडर

यह बिडर, तय की गई दर तक कॉलआउट स्वीकार करता है. इसके बाद, कुछ कॉलआउट के लिए गड़बड़ियां दिखाना शुरू कर देता है. ऐसा इंटरनल टाइम आउट की मदद से किया जा सकता है. इसके अलावा, कनेक्टिविटी की क्वेइंग की सुविधा को बंद करके भी ऐसा किया जा सकता है. यह सुविधा Apache पर ListenBackLog से कंट्रोल की जाती है. इसके अलावा, जब इस्तेमाल या इंतज़ार का समय बहुत ज़्यादा हो जाए, तो संभावित तौर पर कनेक्टिविटी को ड्रॉप करने का मोड लागू किया जा सकता है. इसके अलावा, कुछ और तरीके भी अपनाए जा सकते हैं. अगर Google को गड़बड़ी की दर 15% से ज़्यादा दिखती है, तो हम ट्रैफ़िक को कम करना शुरू कर देंगे. "हर अनुरोध का जवाब देने वाले" बिडर के उलट, यह बिडर "अपने नुकसान को कम करता है". इससे अनुरोध की दरें कम होने पर, उसे तुरंत वापस पाना आसान हो जाता है.

इस बिडर के लिए इंतज़ार का ग्राफ़, ओवरलोड के दौरान धीरे-धीरे बढ़ने वाले पैटर्न जैसा दिखता है. यह ग्राफ़, स्वीकार किए जा सकने वाले सबसे ज़्यादा रेट के आस-पास होता है.

"ओवरलोड पर बिड न करने वाला" बिडर

यह बिडर तय दर तक कॉलआउट स्वीकार करता है. इसके बाद, किसी भी तरह के ओवरलोड के लिए "बिड नहीं" वाले जवाब दिखाना शुरू कर देता है. "लोड होने पर गड़बड़ी" बिडर की तरह ही, इसे कई तरीकों से लागू किया जा सकता है. यहां अंतर यह है कि Google को कोई सिग्नल नहीं भेजा जाता. इसलिए, हम कॉलआउट को कभी भी कम नहीं करते. ज़्यादा ट्रैफ़िक को फ़्रंट-एंड मशीनें मैनेज करती हैं. ये सिर्फ़ उतना ट्रैफ़िक बैकएंड तक भेजती हैं जितना वे मैनेज कर सकती हैं.

इस बिडर के लिए इंतज़ार का ग्राफ़ एक प्लैटफ़ॉर्म दिखाता है, जो (कृत्रिम रूप से) व्यस्त समय के दौरान अनुरोध दर के साथ चलना बंद कर देता है. साथ ही, बिड वाले रिस्पॉन्स के हिस्से में भी गिरावट आती है.

हमारा सुझाव है कि "ओवरलोड होने पर गड़बड़ी" को "ओवरलोड होने पर बिड न करने" के तरीके के साथ इस तरह जोड़ा जाए:

• फ़्रंट-एंड की संख्या ज़्यादा से ज़्यादा रखें और उन्हें ओवरलोड होने पर गड़बड़ी के तौर पर सेट करें. इससे, उन कनेक्शन की संख्या बढ़ाने में मदद मिलेगी जिनका जवाब वे किसी भी तरह दे सकते हैं.
• ओवरलोड होने पर, फ़्रंट-एंड मशीनें पहले से तैयार "बिड नहीं" वाले जवाब का इस्तेमाल कर सकती हैं. साथ ही, उन्हें अनुरोध को पार्स करने की ज़रूरत नहीं होती.
• बैकएंड की परफ़ॉर्मेंस की जांच करने की सुविधा लागू करें, ताकि अगर किसी बैकएंड में ज़रूरत के मुताबिक क्षमता उपलब्ध न हो, तो वह "बिड नहीं" वाला रिस्पॉन्स दिखाए.

इससे कुछ ओवरलोड को कम किया जा सकता है और बैकएंड को उतने अनुरोधों का जवाब देने का मौका मिलता है जितना वे हैंडल कर सकते हैं. इसे "ओवरलोड होने पर बिड न लगाना" माना जा सकता है. जब अनुरोधों की संख्या, अनुमान से काफ़ी ज़्यादा हो जाती है, तो फ़्रंट-एंड मशीनें "ओवरलोड होने पर गड़बड़ी" पर वापस आ जाती हैं.

अगर आपके पास "हर चीज़ का जवाब दें" बिडर है, तो कनेक्शन के व्यवहार को ट्यून करके, इसे "ओवरलोड होने पर गड़बड़ी" बिडर में बदलें. इससे, यह ओवरलोड होने से बच जाता है. इस वजह से, ज़्यादा गड़बड़ियां दिखती हैं. हालांकि, इससे टाइम आउट कम हो जाता है और सर्वर को उस स्थिति में आने से रोका जाता है जहां वह किसी भी अनुरोध का जवाब नहीं दे सकता.

पीयरिंग का इस्तेमाल करना

नेटवर्क के इंतज़ार का समय या बदलाव को कम करने का एक और तरीका है, Google के साथ पीयर करना. पीयरिंग की मदद से, बिडिंग सिस्टम तक पहुंचने के लिए ट्रैफ़िक के पाथ को ऑप्टिमाइज़ किया जा सकता है. कनेक्शन एंडपॉइंट में कोई बदलाव नहीं होता, लेकिन इंटरमीडिएट लिंक बदल जाते हैं. ज़्यादा जानकारी के लिए, पीयरिंग गाइड देखें. पीयरिंग को सबसे सही तरीका मानने की वजहों को इस तरह समझा जा सकता है:

• इंटरनेट पर, ट्रांज़िट लिंक मुख्य रूप से "हॉट-पॉटैटो रूटिंग" की मदद से चुने जाते हैं. यह हमारे नेटवर्क के बाहर, सबसे नज़दीक का ऐसा लिंक ढूंढता है जिससे पैकेट को उसके डेस्टिनेशन तक पहुंचाया जा सकता है. साथ ही, पैकेट को उस लिंक से रूट करता है. जब ट्रैफ़िक, सेवा देने वाली उस कंपनी के मालिकाना हक वाले बैकबोन सेक्शन से गुज़रता है जिसके साथ हमारे कई पीयरिंग कनेक्शन हैं, तो चुना गया लिंक उस जगह के आस-पास हो सकता है जहां पैकेट शुरू होता है. इसके बाद, बिड लगाने वाले को पैकेट भेजने के रास्ते पर हमारा कोई कंट्रोल नहीं होता. इसलिए, रास्ते में यह पैकेट, अन्य ऑटोनॉमस सिस्टम (नेटवर्क) पर भी भेजा जा सकता है.

• इसके उलट, जब डायरेक्ट पीयरिंग का कानूनी समझौता होता है, तो पैकेट को हमेशा पीयरिंग लिंक के ज़रिए भेजा जाता है. पैकेट चाहे कहीं से भी शुरू हो, वह Google के मालिकाना हक वाले या लीज़ पर लिए गए लिंक से होकर, शेयर किए गए पीयरिंग पॉइंट तक पहुंचता है. यह पीयरिंग पॉइंट, बिड लगाने वाले की जगह के आस-पास होना चाहिए. रिवर्स ट्रिप, Google नेटवर्क पर एक छोटे से हॉप से शुरू होता है और बाकी समय Google नेटवर्क पर ही रहता है. ज़्यादातर ट्रिप को Google के मैनेज किए जा रहे इन्फ़्रास्ट्रक्चर पर चलाने से, यह पक्का होता है कि पैकेट कम इंतज़ार वाले रास्ते से गुज़रे. साथ ही, इसकी वजह से, पैकेट में बदलाव होने की संभावना भी कम हो जाती है.

स्टैटिक डीएनएस सबमिट करना

हमारा सुझाव है कि खरीदार हमेशा Google को एक स्टैटिक डीएनएस नतीजा सबमिट करें और ट्रैफ़िक डिलीवरी को मैनेज करने के लिए Google पर भरोसा करें.

बिड लगाने वाले लोगों या कंपनियों के डीएनएस सर्वर, लोड बैलेंस करने या उपलब्धता मैनेज करने के लिए, ये दो सामान्य तरीके अपनाते हैं:

1. डीएनएस सर्वर, किसी क्वेरी के जवाब में एक पता या पतों का सबसेट देता है. इसके बाद, वह इस जवाब को किसी तरीके से साइकल करता है.
2. डीएनएस सर्वर हमेशा पतों के एक ही सेट के साथ जवाब देता है, लेकिन रिस्पॉन्स में पतों का क्रम बदलता रहता है.

पहली तकनीक, लोड बैलेंस करने में खराब है, क्योंकि स्टैक के कई लेवल पर बहुत ज़्यादा कैश मेमोरी होती है. साथ ही, कैश मेमोरी को बायपास करने की कोशिश करने पर भी, शायद पसंदीदा नतीजे न मिलें. इसकी वजह यह है कि Google, बिडर से डीएनएस रिज़ॉल्यूशन के समय के लिए शुल्क लेता है.

दूसरी तकनीक से लोड बैलेंसिंग नहीं होती, क्योंकि Google, डीएनएस रिस्पॉन्स की सूची से किसी आईपी पते को चुनता है. इसलिए, रिस्पॉन्स के क्रम से कोई फ़र्क़ नहीं पड़ता.

अगर बिडर डीएनएस में बदलाव करता है, तो Google अपने डीएनएस रिकॉर्ड में सेट किए गए टीटीएल(लाइव रहने का समय) का पालन करेगा. हालांकि, रीफ़्रेश इंटरवल के बारे में कोई भरोसा नहीं किया जा सकता.