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

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

कनेक्शन प्रबंधित करें

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

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

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

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

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

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

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

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

हमारा सुझाव है कि ओवरलोड पर "गड़बड़ी और ओवरलोड पर 'नो-बिड' को अलग-अलग तरीके से मिलाएं:

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

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

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

पिंग का जवाब दें

यह पक्का करना ज़रूरी है कि बोली लगाने वाला व्यक्ति पिंग करने के अनुरोधों का जवाब दे. हालांकि, हर स्रोत के लिए कनेक्शन मैनेज नहीं करना, डीबग करने के लिए बेहद ज़रूरी है. 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"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

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

मिलते-जुलते ऐप्लिकेशन से जुड़ने के बारे में सोचें

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

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

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

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

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

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

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

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

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

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