Airbnb में Node.js और सर्वर रेंडरिंग

सामग्री, जिसका अनुवाद आज हम प्रकाशित कर रहे हैं, यह कहानी है कि कैसे Airbnb सर्वर रेंडरिंग प्रौद्योगिकियों के बढ़ते उपयोग के लिए एक आंख के साथ वेब अनुप्रयोगों के सर्वर भागों का अनुकूलन करता है। कई वर्षों के दौरान, कंपनी ने धीरे-धीरे अपने पूरे फ्रंट-एंड को एक समान आर्किटेक्चर में स्थानांतरित कर दिया, जिसके अनुसार वेब पेज उनके एपीआई से डेटा से भरे रिएक्ट घटकों के पदानुक्रमित संरचनाएं हैं। विशेष रूप से, इस प्रक्रिया के दौरान पटरियों पर रूबी का एक व्यवस्थित परित्याग था। वास्तव में, Airbnb की योजना पूरी तरह से Node.js पर आधारित एक नई सेवा पर स्विच करने की है, जिसके लिए सर्वर पर प्रदान किए गए पूरी तरह से तैयार किए गए पृष्ठ को उपयोगकर्ताओं के ब्राउज़रों तक पहुंचाया जाएगा। यह सेवा सभी Airbnb उत्पादों के लिए अधिकांश HTML कोड उत्पन्न करेगी। प्रश्न में रेंडरिंग इंजन कंपनी द्वारा उपयोग की जाने वाली अधिकांश बैकेंड सेवाओं से भिन्न है, क्योंकि यह रूबी या जावा में नहीं लिखा गया है। हालाँकि, यह पारंपरिक अत्यधिक भरी हुई Node.js सेवाओं से भिन्न है, जिसके आसपास Airbnb में उपयोग किए जाने वाले मानसिक मॉडल और सहायक उपकरण बनाए गए हैं।

Node.js मंच

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

सर्वर साइड रेंडरिंग (SSR) मूल विचारों को बदलता है जिससे समस्या का एक समान दृष्टिकोण होता है। इसलिए, सर्वर रेंडरिंग को बहुत सारे कंप्यूटिंग संसाधनों की आवश्यकता होती है। Node.js परिवेश में कोड को एक ही थ्रेड में निष्पादित किया जाता है, परिणामस्वरूप कम्प्यूटेशनल समस्याओं को हल करने के लिए (I / O कार्यों के विपरीत), कोड को एक साथ निष्पादित किया जा सकता है, लेकिन समानांतर में नहीं। Node.js प्लेटफ़ॉर्म बड़ी संख्या में समानांतर I / O संचालन को संभालने में सक्षम है, हालांकि, जब कंप्यूटिंग की बात आती है, तो स्थिति बदल जाती है।

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

Promise.all([fn1, fn2]) फॉर्म की एक कमांड पर विचार करें। यदि fn1 या fn2 I / O सबसिस्टम द्वारा हल किए गए वादे हैं, तो इस कमांड के निष्पादन के दौरान परिचालन के समानांतर निष्पादन को प्राप्त करना संभव है। यह इस तरह दिखता है:


इनपुट / आउटपुट सबसिस्टम के माध्यम से संचालन का समानांतर निष्पादन

यदि fn1 और fn2 कम्प्यूटेशनल कार्य हैं, तो उन्हें निम्नानुसार निष्पादित किया जाएगा:


कम्प्यूटिंग कार्य

एक ऑपरेशन को दूसरे ऑपरेशन के पूरा होने का इंतजार करना होगा, क्योंकि Node.js. में केवल एक धागा है।

सर्वर रेंडरिंग के मामले में, यह समस्या तब होती है जब सर्वर प्रक्रिया को एक साथ कई अनुरोधों को संसाधित करना पड़ता है। इस तरह के अनुरोधों के प्रसंस्करण में देरी होगी जब तक कि पहले प्राप्त अनुरोध संसाधित नहीं हो जाते। यहाँ है कि यह कैसा दिखता है।


समवर्ती अनुरोध संसाधित करना

व्यवहार में, अनुरोध प्रसंस्करण में अक्सर कई अतुल्यकालिक चरण होते हैं, भले ही वे सिस्टम पर एक गंभीर कम्प्यूटेशनल लोड शामिल हों। यह इस तरह के अनुरोधों को संसाधित करने के लिए कार्यों के वैकल्पिककरण के साथ और भी कठिन स्थिति पैदा कर सकता है।

मान लीजिए कि हमारी क्वेरीज़ एक कार्य श्रृंखला से बनी हैं जो इस से मिलती जुलती है: renderPromise().then(out => formatResponsePromise(out)).then(body => res.send(body)) । जब सिस्टम में इस तरह के अनुरोधों की एक जोड़ी आती है, तो उनके बीच एक छोटे से अंतराल के साथ, हम निम्नलिखित तस्वीर का पालन कर सकते हैं।


प्रसंस्करण अनुरोध जो एक छोटे से अंतराल पर पहुंचते हैं, प्रोसेसर संसाधनों के लिए संघर्ष की समस्या

इस मामले में, प्रत्येक अनुरोध को संसाधित करने में लगभग दोगुना समय लगता है, जितना कि किसी व्यक्तिगत अनुरोध को संसाधित करने में लगता है। एक साथ संसाधित अनुरोधों की संख्या में वृद्धि के साथ, स्थिति और भी बदतर हो जाती है।

इसके अलावा, SSR कार्यान्वयन के विशिष्ट लक्ष्यों में से एक क्लाइंट या सर्वर पर समान या बहुत समान कोड का उपयोग करने की क्षमता है। इन वातावरणों के बीच गंभीर अंतर यह है कि ग्राहक पर्यावरण अनिवार्य रूप से एक ऐसा वातावरण है जिसमें एक ग्राहक संचालित होता है, और सर्वर वातावरण, उनकी प्रकृति से, बहु-ग्राहक वातावरण होते हैं। क्लाइंट पर अच्छी तरह से काम करता है, जैसे कि आवेदन की वैश्विक स्थिति को संग्रहीत करने के लिए एकल या अन्य दृष्टिकोण, त्रुटियों की ओर जाता है, डेटा लीक, और, सामान्य रूप से, भ्रम की स्थिति में, सर्वर पर आने वाले कई अनुरोधों को संसाधित करते समय।

ये सुविधाएँ उस स्थिति में समस्या बन जाती हैं जहाँ आपको एक ही समय में कई अनुरोधों को संसाधित करने की आवश्यकता होती है। सब कुछ आमतौर पर विकास के माहौल के एक आरामदायक वातावरण में कम भार के तहत काफी सामान्य रूप से काम करता है, जिसका उपयोग प्रोग्रामर के व्यक्ति में एक ग्राहक द्वारा किया जाता है।

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

हाइपरनोवा प्रोजेक्ट ट्यूटोरियल

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

हाइपरनोवा हमारी नई सेवा की तरह काम नहीं करती है। यह एक शुद्ध प्रतिपादन प्रणाली है। इसे हमारी मोनोलिथिक रेल सेवा से कहा जाता है, जिसे मोनोरेल कहा जाता है, और विशिष्ट प्रदान किए गए घटकों के लिए केवल HTML स्निपेट लौटाता है। कई मामलों में, यह "स्निपेट" पृष्ठ के शेर के हिस्से का प्रतिनिधित्व करता है, और रेल केवल पृष्ठ लेआउट प्रदान करता है। विरासत तकनीक के साथ, एक पृष्ठ के कुछ हिस्सों को ईआरबी का उपयोग करके एक साथ जोड़ा जा सकता है। किसी भी मामले में, हालांकि, हाइपरनोवा पेज बनाने के लिए आवश्यक किसी भी डेटा को लोड नहीं करता है। यह रेल का कार्य है।

इस प्रकार, हाइपरलूप और हाइपरनोवा में समान कंप्यूटिंग प्रदर्शन होता है। उसी समय, हाइपरनोवा, उत्पादन सेवा और यातायात के महत्वपूर्ण संस्करणों को संसाधित करने के रूप में, परीक्षण के लिए एक अच्छा क्षेत्र प्रदान करता है, जिससे हाइपरनोवा प्रतिस्थापन का मुकाबला करने की स्थिति में कैसे व्यवहार होगा, इसकी समझ पैदा होती है।


हाइपरनोवा वर्कफ़्लो

यहां बताया गया है कि हाइपरनोवा कैसे काम करता है। उपयोगकर्ता अनुरोध हमारे मुख्य रेल एप्लिकेशन पर आते हैं, मोनोरेल, जो रिएक्ट घटकों के गुणों को एकत्र करता है, जिन्हें एक पृष्ठ पर प्रदर्शित करने की आवश्यकता होती है और इन गुणों और घटक नामों को पारित करते हुए हाइपरनोवा के लिए अनुरोध करता है। हाइपरनोवा HTML कोड उत्पन्न करने के लिए गुणों के साथ घटकों को प्रस्तुत करता है जिसे मोनोरेल एप्लिकेशन को वापस करने की आवश्यकता होती है, जो तब इस कोड को पेज टेम्पलेट में एम्बेड करता है और इसे सभी क्लाइंट को वापस भेजता है।


एक ग्राहक को एक समाप्त पृष्ठ भेजना

हाइपरनोवा में एक आपातकालीन स्थिति में (यह एक त्रुटि या प्रतिक्रिया समयबाह्य हो सकती है), एक बैकबैक विकल्प है, जिसका उपयोग करते समय सर्वर पर उत्पन्न HTML के बिना घटकों और उनके गुणों को पृष्ठ में एम्बेड किया जाता है, जिसके बाद यह सब क्लाइंट को भेजा जाता है और वहां प्रदान किया जाता है उम्मीद है कि सफल। यह हमें इस तथ्य की ओर ले गया कि हमने हाइपरनोवा सेवा को प्रणाली का महत्वपूर्ण हिस्सा नहीं माना। नतीजतन, हम एक निश्चित संख्या में विफलताओं और स्थितियों की घटना की अनुमति दे सकते हैं जिसमें एक समयबाह्य ट्रिगर होता है। अनुरोध टाइमआउट को समायोजित करके, हम टिप्पणियों के आधार पर, उन्हें लगभग पी 95 तक सेट करते हैं। नतीजतन, यह आश्चर्यजनक नहीं है कि सिस्टम ने 5% से कम की बेस टाइमआउट प्रतिक्रिया दर के साथ काम किया।

ऐसी स्थितियों में जब ट्रैफ़िक चरम मूल्यों पर पहुंच गया, हम देख सकते थे कि हाइपरनोवा के लिए 40% तक अनुरोध मोनोरेल में टाइमआउट द्वारा बंद कर दिए गए थे। हाइपरनोवा की ओर से, हमने BadRequestError: Request aborted चोटियों को देखा BadRequestError: Request aborted निचली ऊंचाई की BadRequestError: Request aborted । इसके अलावा, ये त्रुटियां सामान्य परिस्थितियों में मौजूद थीं, जबकि सामान्य ऑपरेशन में, समाधान की वास्तुकला के कारण, शेष त्रुटियां विशेष रूप से ध्यान देने योग्य नहीं थीं।


पीक टाइमआउट मान (लाल रेखाएँ)

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

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


अनुसंधान के परिणाम

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

इसके अलावा, यह और अधिक स्पष्ट कर दिया कि BadRequestError: Request aborted को एक धीमी प्रणाली स्टार्टअप द्वारा आत्मविश्वास से समझाया नहीं जा सकता है। त्रुटि अनुरोध निकाय के पार्सिंग कोड से आगे बढ़ी, और तब हुई जब क्लाइंट ने अनुरोध को रद्द कर दिया, इससे पहले कि सर्वर अनुरोध शरीर को पूरी तरह से पढ़ सके। क्लाइंट ने काम करना बंद कर दिया, कनेक्शन बंद कर दिया, हमें उस डेटा से वंचित कर दिया जो अनुरोध को जारी रखने के लिए आवश्यक है। यह बहुत अधिक संभावना है कि ऐसा इसलिए हुआ क्योंकि हमने अनुरोध को संसाधित करना शुरू कर दिया था, उसके बाद इवेंट लूप एक अन्य अनुरोध के लिए एक अवरुद्ध प्रतिपादन निकला, और फिर हम इसे पूरा करने के लिए बाधित कार्य पर लौट आए, लेकिन परिणामस्वरूप यह निकला कि ग्राहक जिसने हमें यह अनुरोध भेजा है, उसने पहले ही अनुरोध को समाप्त कर दिया है। इसके अलावा, हाइपरनोवा के अनुरोधों में प्रेषित डेटा कई सौ किलोबाइट्स के क्षेत्र में, औसतन, बहुत अधिक चमकदार था, और निश्चित रूप से, इसने स्थिति को सुधारने में योगदान नहीं दिया।


एक क्लाइंट को डिस्कनेक्ट करने के कारण त्रुटि हुई जो प्रतिक्रिया के लिए इंतजार नहीं करता था

हमने मानक उपकरणों के एक जोड़े का उपयोग करके इस समस्या से निपटने का फैसला किया, जिनके साथ हमारे पास काफी अनुभव था। हम एक रिवर्स प्रॉक्सी सर्वर ( nginx ) और एक लोड बैलेंसर ( HAProxy ) के बारे में बात कर रहे हैं।

रिवर्स प्रॉक्सिंग और लोड बैलेंसिंग

मल्टी-कोर प्रोसेसर आर्किटेक्चर का लाभ उठाने के लिए, हम अंतर्निहित Node.js क्लस्टर मॉड्यूल का उपयोग करके कई हाइपरनोवा प्रक्रियाएं चलाते हैं। चूंकि ये प्रक्रियाएं स्वतंत्र हैं, हम एक साथ आने वाले अनुरोधों को संसाधित कर सकते हैं।


एक साथ आने वाले अनुरोधों का समानांतर प्रसंस्करण

यहां समस्या यह है कि प्रत्येक नोड प्रक्रिया एक अनुरोध को संसाधित करने में हर समय पूरी तरह से व्यस्त है, जिसमें क्लाइंट से भेजे गए अनुरोध के शरीर को पढ़ना शामिल है (मोनोरेल इस मामले में अपनी भूमिका निभाता है)। यद्यपि हम एक ही समय में एक ही प्रक्रिया में कई प्रश्नों को पढ़ सकते हैं, जब यह प्रतिपादन की बात आती है, तो यह कम्प्यूटेशनल संचालन के एक विकल्प की ओर जाता है।

नोड प्रक्रिया संसाधनों का उपयोग क्लाइंट और नेटवर्क स्पीड से जुड़ा हुआ है।

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


Nginx बफ़र्स अनुरोध करता है और फिर उन्हें नोड सर्वर को भेजता है

इस तथ्य के कारण कि nginx अब पढ़ने के अनुरोधों में व्यस्त है, हम नोड प्रक्रियाओं की अधिक समान लोडिंग को प्राप्त करने में सक्षम थे।

Nginx का उपयोग करके वर्दी प्रक्रिया लोड करना

इसके अलावा, हमने कुछ अनुरोधों को संभालने के लिए nginx का उपयोग किया है जिन्हें नोड प्रक्रियाओं तक पहुंच की आवश्यकता नहीं है। हमारी सेवा का पता लगाने और रूट करने की परतें उन अनुरोधों का उपयोग करती हैं जो मेजबानों के बीच संचार को सत्यापित करने के लिए सिस्टम पर एक बड़ा भार नहीं बनाते हैं। Nginx में यह सब संसाधित करने से Node.js. के लिए अतिरिक्त (यद्यपि छोटा) कार्यभार का एक महत्वपूर्ण स्रोत समाप्त हो जाता है

अगला सुधार चिंताओं को संतुलित करता है। हमें नोड प्रक्रियाओं के बीच अनुरोधों के वितरण के बारे में सूचित निर्णय लेने की आवश्यकता है। cluster मॉड्यूल राउंड-रॉबिन एल्गोरिथ्म के अनुसार अनुरोधों को वितरित करता है, ज्यादातर मामलों में प्रक्रियाओं को बायपास करने के प्रयासों के साथ जो अनुरोधों का जवाब नहीं देते हैं। इस दृष्टिकोण के साथ, प्रत्येक प्रक्रिया को प्राथमिकता के क्रम में एक अनुरोध प्राप्त होता है।

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

अनुरोध विलंब में कम परिवर्तनशीलता होने पर राउंड-रॉबिन एल्गोरिथ्म अच्छा है। उदाहरण के लिए, नीचे दी गई स्थिति में।


राउंड-रॉबिन एल्गोरिथ्म और कनेक्शन जिनके माध्यम से अनुरोधों को सख्ती से प्राप्त किया जाता है

यह एल्गोरिथ्म पहले से ही इतना अच्छा नहीं है जब आपको विभिन्न प्रकार के अनुरोधों को संसाधित करना पड़ता है, जिसके प्रसंस्करण के लिए पूरी तरह से अलग समय की लागतों की आवश्यकता हो सकती है। एक निश्चित प्रक्रिया को भेजा गया सबसे हालिया अनुरोध पहले भेजे गए सभी अनुरोधों को पूरा करने के लिए प्रतीक्षा करने के लिए मजबूर है, भले ही एक और प्रक्रिया हो जिसमें इस तरह के अनुरोध को संसाधित करने की क्षमता हो।


असमान प्रक्रिया भार

यदि आप ऊपर दिए गए प्रश्नों को अधिक तर्कसंगत रूप से वितरित करते हैं, तो आपको नीचे दी गई आकृति में दिखाए गए जैसा कुछ मिलता है।


धागे द्वारा अनुरोधों का तर्कसंगत वितरण

इस दृष्टिकोण के साथ, प्रतीक्षा कम से कम हो जाती है और अनुरोधों को तेज़ी से प्रतिक्रियाएं भेजना संभव हो जाता है।

यह एक कतार में अनुरोधों को रखकर प्राप्त किया जा सकता है, और उन्हें केवल एक प्रक्रिया में असाइन करना जब वह किसी अन्य अनुरोध को संसाधित करने में व्यस्त न हो। इस उद्देश्य के लिए हम HAProxy का उपयोग करते हैं।


HAProxy और प्रक्रिया लोड संतुलन

जब हमने हाइपरनोवा पर लोड को संतुलित करने के लिए HAProxy का उपयोग किया, तो हमने टाइमआउट चोटियों, साथ ही BadRequestErrors त्रुटियों को पूरी तरह से समाप्त कर दिया।

सामान्य ऑपरेशन के दौरान होने वाले विलंब भी मुख्य कारण थे; इस दृष्टिकोण ने इस तरह की देरी को कम कर दिया। इसके परिणामों में से एक यह था कि अब केवल 2% अनुरोधों को टाइमआउट द्वारा बंद कर दिया गया था, और 5% नहीं, एक ही टाइमआउट सेटिंग्स के साथ। तथ्य यह है कि हम एक स्थिति से 40% त्रुटियों के साथ एक स्थिति से स्थानांतरित करने में कामयाब रहे समयबाह्य 2% मामलों में ट्रिगर करने के साथ दिखाया गया है कि हम सही दिशा में आगे बढ़ रहे हैं। परिणामस्वरूप, आज हमारे उपयोगकर्ता वेबसाइट की लोडिंग स्क्रीन को बहुत कम बार देखते हैं। यह ध्यान दिया जाना चाहिए कि एक नई प्रणाली के लिए अपेक्षित संक्रमण के साथ सिस्टम स्थिरता हमारे लिए विशेष महत्व की होगी जिसमें वही बैकअप तंत्र नहीं है जो हाइपरनोवा के पास है।

सिस्टम और इसकी सेटिंग्स के बारे में विवरण

यह सब काम करने के लिए, आपको nginx, HAProxy और Node एप्लिकेशन को कॉन्फ़िगर करना होगा। यहाँ nginx और HAProxy का उपयोग करके एक समान एप्लिकेशन का एक उदाहरण है , जिसका विश्लेषण करते हुए, आप सिस्टम के डिवाइस को प्रश्न में समझ सकते हैं। यह उदाहरण उस प्रणाली पर आधारित है जिसका उपयोग हम उत्पादन में करते हैं, लेकिन इसे सरल और संशोधित किया जाता है ताकि इसे अप्रकाशित उपयोगकर्ता की ओर से अग्रभूमि में निष्पादित किया जा सके। उत्पादन में, कुछ प्रकार के पर्यवेक्षक का उपयोग करके सब कुछ कॉन्फ़िगर किया जाना चाहिए (हम रनिट का उपयोग करते हैं, या, अधिक बार, कुबेरनेट्स)।

नेगनेक्स कॉन्फ़िगरेशन बहुत मानक है, यह एक सर्वर का उपयोग करता है जो पोर्ट 9000 पर सुनता है, HAProxy सर्वर पर प्रॉक्सी अनुरोधों के लिए कॉन्फ़िगर किया गया है, जो पोर्ट 9001 (हमारे कॉन्फ़िगरेशन में, हम यूनिक्स डोमेन सॉकेट्स का उपयोग करते हैं) को सुनते हैं।

इसके अलावा, यह सर्वर नेटवर्क कनेक्टिविटी की जाँच करने के उद्देश्य से सीधे सेवा अनुरोधों के लिए /ping समापन बिंदु के लिए अनुरोधों को स्वीकार करता है। nginx , worker_processes 1, nginx — HAProxy Node-. , , , Hypernova, ( ). .

Node.js cluster . HAProxy, cluster , . pool-hall . — , , , cluster , . pool-hall , .

HAProxy , 9001 , 9002 9005. — maxconn 1 , . . HAProxy ( 8999).


HAProxy

HAProxy . , maxconn . static-rr (static round-robin), , , . , round-robin, , , , , . , , . .

, , . ( ). , , , , . , , .

HAProxy

HAProxy. , , , . , , ( ) . , , cluster . , .

ab (Apache Benchmark) 10000 . - . :

 ab -l -c <CONCURRENCY> -n 10000 http://<HOSTNAME>:9000/render 

15 4- -, ab , . ( concurrency=5 ), ( concurrency=13 ), , ( concurrency=20 ). , .

, -, . , . , , , , . , , , .

, — .

maxconn 1 , , .

HTTP TCP , , , . , maxconn , . , , (, , ).

, , , , , , .

— , . option redispatch retries 3 , , , , , , . .

, - , . , . , , . 100 , 10 , , . , . , accept .

, ( backlog ) , . SYN-ACK ( , , , ACK ). , , , , .

, , , , . , , 1. maxconn . 0 , , , , , . , . - , , . abortonclose , . , abortonclose . nginx.

, , . ( ) , , , , , . HAProxy , , ( ). , , , HTML. , , . , , ( , , ). , , . , , , . HAProxy, MAINT HAProxy.

, , , server.close Node.js , HAProxy , , , . , , , , , .

, , balance first , ( worker1 ) 15% , , , balance static-rr . , «» . . (12 ), , , - . , , , «» «». .

, , Node server.maxconnections , ( , ), , , , . , maxconnection , , , . JavaScript, ( ). , , , . , , , HAProxy Node , . , , .

, , , , .

Node.js . , , , -. Node.js . , , , , , , , nginx HAProxy.

, Airbnb , Node.js .

प्रिय पाठकों! ?