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

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

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

अपने कनेक्शन को चालू रखें

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

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

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

कनेक्शन बंद करने से बचें

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

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

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

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

कनेक्शन को संतुलित रखें

अगर Authorized Buyers, किसी प्रॉक्सी सर्वर के ज़रिए बिड करने वाले के सर्वर से कनेक्ट होता है, तो समय के साथ कनेक्शन असंतुलित हो सकते हैं. ऐसा इसलिए होता है, क्योंकि सिर्फ़ प्रॉक्सी सर्वर का आईपी पता पता होने पर, Authorized Buyers यह तय नहीं कर सकता है कि बिडिंग करने वाले किस सर्वर को हर कॉलआउट मिलेगा. समय के साथ, जब 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

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

ओपनआरटीबी प्रोटोबफ़

id: "7xd2P2M7K32d7F7Y50p631"

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

ध्यान रखें कि आपकी उम्मीद के उलट, पिंग अनुरोध में कोई विज्ञापन स्लॉट नहीं है. साथ ही, जैसा कि ऊपर बताया गया है, आपको किसी पिंग अनुरोध का जवाब देने के बाद कनेक्शन बंद नहीं करना चाहिए.

पीयरिंग पर विचार करें

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

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

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

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

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

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

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

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

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

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