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

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

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

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

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

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

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

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

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

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

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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

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

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

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

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

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

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

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

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

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

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

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

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