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

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

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

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

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

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

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

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

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

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

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

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

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

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

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

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

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

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

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

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

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

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

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

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

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

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

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

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