👀 ☯️ 📧 Node.js पर एक साथ मिलियन कनेक्शन 👩🏽‍🚀 👰🏼 🤦🏻

टीएल; डीआर:

Node.js v0.8 आपको इंटेल कोर i7 क्वाड / 16 जीबी रैम पर 1 मिलियन एक साथ HTTP धूमकेतु कनेक्शन को संसाधित करने की अनुमति देता है वस्तुतः बिना किसी अतिरिक्त सेटिंग्स के।
1 कनेक्शन 10 Kb से अधिक मेमोरी (4.1 Kb Javascript हीप + 2.2 Kb Node.js नेटिव + 3.8 Kb कर्नेल) का उपयोग करता है।
V8 कचरा संग्रहक का प्रबंधन करने के लिए डिज़ाइन नहीं किया गया है ~ ~ 500Mb स्मृति। यदि अधिक हो, तो आपको वैकल्पिक कचरा संग्रह मोड में स्विच करना होगा, अन्यथा सर्वर की जवाबदेही बहुत कम हो जाती है।
ऐसा अनुभव (और चाहिए!) बहुत अधिक खर्च किए बिना खुद को दोहराया जाए (बिल्ली के नीचे देखें)।

परिचय

विदेशी ब्लॉगों में, मोचीवब / एर्लांग के साथ क्लासिक ए मिलियन उपयोगकर्ता धूमकेतु अनुप्रयोग से , हाल ही में Node.js w / 250k समवर्ती कनेक्शन के लिए अधिकतम एक साथ कनेक्शन के कई परीक्षणों की समीक्षा की गई। मैं अपने परीक्षण में जो हासिल करना चाहूंगा, वह है दोहराव। ताकि अन्य लोग बिना किसी समस्या के अपना परीक्षा परिणाम दोहरा सकें और प्राप्त कर सकें। परीक्षणों में उपयोग किए जाने वाले सभी कोड जीथब पर पोस्ट किए गए थे: सर्वर और क्लाइंट , स्वागत है।

सर्वर

1. लोहा

बेशक, आपको ऐसे परीक्षणों को चलाने के लिए एक समर्पित सर्वर की आवश्यकता होगी। इसे अपने पसंदीदा होस्टिंग प्रदाता से ऑर्डर करें या किसी मौजूदा का उपयोग करें। मैंने Hetzner EX4 (Core i7-2600 Quad, 16Gb RAM) का इस्तेमाल किया, यह काफी सस्ता और शक्तिशाली है।

2. ऑपरेटिंग सिस्टम

मैं Ubuntu 12.04 LTS का उपयोग कर रहा हूं। शायद मेरे परीक्षण का उपयोग अन्य लिनक्स-एस में मामूली बदलाव के साथ किया जा सकता है। सबसे अधिक संभावना है कि यह अन्य ओएस पर काम नहीं करेगा। नेटवर्क ने बड़ी संख्या में कनेक्शन के लिए लिनक्स स्थापित करने के बारे में बहुत सारी बातें की हैं। क्या प्रसन्नता है, इसमें से किसी की भी आवश्यकता नहीं थी:

#/etc/security/limits.conf #     (     ). * - nofile 1048576

 #/etc/sysctl.conf #   netfilter/iptables,     : net.ipv4.netfilter.ip_conntrack_max = 1048576

3. Node.js के लिए कोड

सभी परीक्षण Node.js v0.8.3 का उपयोग करते हैं।
हम कई प्रक्रियाओं (कोर की संख्या द्वारा) पर लोड वितरित करने के लिए मानक क्लस्टर मॉड्यूल का उपयोग करते हैं। नागल एल्गोरिथ्म को अक्षम करें।

 // Server.js () var cluster = require('cluster'); var config = { numWorkers: require('os').cpus().length, }; cluster.setupMaster({ exec: "worker.js" }); // Fork workers as needed. for (var i = 0; i < config.numWorkers; i++) cluster.fork()

 // Worker.js () var server = require('http').createServer(); var config = {...}; server.on('connection', function(socket) { socket.setNoDelay(); //   . }); var connections = 0; server.on('request', function(req, res) { connections++; //   ''  20  // = 50     1   var pingInterval = setInterval(function() { res.write('ping'); }, 20*1000); res.writeHead(200); res.write("Welcome!"); res.on('close', function() { connections--; clearInterval(pingInterval); pingInterval = undefined; }); }); server.listen(config.port);

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

 git clone git://github.com/ashtuchkin/node-millenium.git cd node-millenium #     8888. node server.js

हमें इसके समान एक तस्वीर मिलती है:

निम्नलिखित यहाँ ध्यान दिया जाना चाहिए:

प्रोसेसर के उपयोग के प्रतिशत को हर जगह कोर की संख्या दी गई है। यानी 4-कोर प्रोसेसर पर, अधिकतम भार 400% है।
'प्रयुक्त' मेमोरी में buf + कैश शामिल नहीं है। यानी सर्वर पर + मुक्त + (buf + कैश) = कुल मेमोरी का उपयोग किया जाना चाहिए।
प्रत्येक प्रक्रिया के लिए, इसका pid, प्रोसेसर लोड शेयर (उपयोगकर्ता + sys), RSS मेमोरी, कनेक्शन की संख्या, os.memoryUsage () के अनुसार heapUsed / heapTotal, प्रक्रिया की जवाबदेही के तीन आयाम (टिक, नीचे देखें) प्रदर्शित होते हैं।

इस प्रक्रिया की "जवाबदेही" क्या है? सशर्त रूप से, यह है कि इवेंट लूप नोड.जेएस द्वारा संसाधित होने से पहले इवेंट को कितना इंतजार करना होगा यह पैरामीटर उन अनुप्रयोगों में महत्वपूर्ण है जो कम से कम कुछ वास्तविक समय पर भरोसा करते हैं, लेकिन गणना करना मुश्किल है।

हम इसे इस प्रकार मापेंगे:

 //  Node.js      10     . var ticks = []; setInterval(function() { ticks.push(Date.now()); }, 10); //    . setInterval(function() { // 1.    : ticks[i] = ticks[i+1]-ticks[i] // 2.     ticks   (tick-avg), 90-    (tick-max). // 3.         . ticks.length=0; }, 1000);

मैं अलग से नोट करना चाहता हूं कि 10 एमएस के माप अंतराल को त्रुटि और जोड़ के बीच संतुलन के रूप में चुना गया था। सिस्टम लोड। यदि 10/10 / 10ms प्रदर्शित किया जाता है, तो इसका मतलब यह नहीं है कि Node.js प्रत्येक घटना को संसाधित करने पर 10 एमएस खर्च करता है। इसका मतलब यह है कि 10 एमएस माप ग्रिड के साथ, इवेंट लूप हर बार मुफ्त है और किसी भी आने वाली घटना को एक बार में संसाधित करने के लिए तैयार है, जिसका अर्थ है कि प्रसंस्करण घटनाओं के लिए औसत समय बहुत कम है। यदि कचरा कलेक्टर, या लंबे समय तक संचालन होता है, तो हम तुरंत इसे देखेंगे और ठीक करेंगे।

लॉग को CSV प्रारूप में बनाए रखा जाता है, जहां एक बार सिस्टम के सभी कुल आंकड़ों को नोट किया जाता है ( गिथब पर सूची देखें)।

ग्राहकों

विचित्र रूप से पर्याप्त है, एक सर्वर बनाने की तुलना में आवश्यक भार प्रदान करना अधिक कठिन था। तथ्य यह है कि एक टीसीपी कनेक्शन चार [स्रोत आईपी, स्रोत पोर्ट, डेस्ट आईपी, डेस्ट पोर्ट] द्वारा विशिष्ट रूप से निर्धारित किया जाता है, इसलिए एक मशीन से 1 सर्वर पोर्ट तक आप 64 हजार से अधिक एक साथ कनेक्शन (स्रोत पोर्ट की संख्या से) नहीं बना सकते हैं। यहां वर्णित विभिन्न आईपी के साथ 16 नेटवर्क इंटरफेस बनाना संभव होगा, लेकिन मशीन होस्ट पर होने पर यह मुश्किल है।

परिणामस्वरूप, अमेज़ॅन ईसी 2 माइक्रो इंस्टेंस का उपयोग 2 सेंट प्रति घंटे करने का निर्णय लिया गया। यह पाया गया कि ऐसी मशीन, प्रोसेसर पर सीमाओं के कारण और, विशेष रूप से, मेमोरी, लगभग 25 हजार कनेक्शन रखती है। इस प्रकार, 40 चलने वाले उदाहरण हमें 1 मिलियन कनेक्शन प्रदान करेंगे और प्रति घंटे $ 0.8 खर्च होंगे। यह काफी स्वीकार्य है।

अलग-अलग, मुझे कहना होगा कि डिफ़ॉल्ट रूप से अमेज़ॅन आपको एक क्षेत्र में ~ 20 से अधिक उदाहरण नहीं जुटाने देगा। आप या तो इस सीमा को बढ़ाने का अनुरोध छोड़ सकते हैं, या कई क्षेत्रों में उदाहरण बढ़ा सकते हैं। मैंने बाद वाला चुना।

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

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

क्या अच्छा है - उदाहरणों के प्रत्येक लॉन्च से पहले क्लाइंट कोड को संपादित किया जा सकता है।

आप अपने आप को ec2-बेड़े प्रोजेक्ट और निम्न आदेशों का उपयोग करके आज़मा सकते हैं:

 git clone git://github.com/ashtuchkin/ec2-fleet.git cd ec2-fleet #     npm install #    accessKeyId, accessKeySecret     Amazon. # https://portal.aws.amazon.com/gp/aws/securityCredentials # ,        (  ) # !         Security Group 'default'   # TCP  8889  source 0.0.0.0/0 -       . nano aws-config.json # , , 10    . #     . ,     . ./aws.js start 10 #      (  top).     . ./aws.js status #   (,     ,   ) ./aws.js set host <ip> #     1000  ./aws.js set n 1000 #    - 25000  ./aws.js set n 25000 #     .    . ./aws.js set restart 1 #      .  -  . ./aws.js stop all

परीक्षण

तो ठीक है, चलो परीक्षण शुरू करते हैं। यहां और निम्नलिखित परीक्षणों में हम 1 मिलियन कनेक्शन, 50 हजार संदेश प्रति सेकंड करेंगे। Node.js संस्करण v0.8.3। सर्वर कोर की संख्या के अनुसार प्रसंस्करण 8 प्रक्रियाओं ("श्रमिकों") में किया जाएगा।

नोड server.js

पहले परीक्षण में, हम मानक कॉन्फ़िगरेशन में ही अतिरिक्त झंडे के बिना नोड.जेएस चलाएंगे। हम पहला परीक्षण शुरू करते हैं (सभी तस्वीरें क्लिक करने योग्य हैं):

सभी ग्राफ़ पर, काली बिंदीदार रेखा अधिकतम 1 मिलियन के साथ कनेक्शन की संख्या को इंगित करती है। परीक्षण की शुरुआत से क्षैतिज - सेकंड, ऊर्ध्वाधर लाइनें मिनट दर्शाती हैं। मेमोरी ग्राफ़ दिखाते हैं: कुल - प्रयुक्त मेमोरी की कुल संख्या (मुझे याद है, परीक्षण 16 जीबी की कुल मेमोरी क्षमता वाले सर्वर पर आयोजित किया गया था), कुल नेट्टो - पहले सेकंड की तुलना में कुल में वृद्धि (यह पेश किया गया था क्योंकि कुछ और इस मशीन पर कताई है मेरी परियोजनाओं में, कुल मिलाकर वे ~ 1.3 जीबी), आरएसएस मेम, जेएस हीप टोटल, जेएस हीप प्रयुक्त - कुल आरएसएस मूल्य (लिंक), जेएस हीप कुल, जेएस हीप सभी नोड का उपयोग करते हैं। जेएस प्रक्रियाएं।

नेत्रहीन, ग्रे क्षेत्र का आकार कर्नेल द्वारा आवंटित स्मृति की मात्रा को इंगित करता है, पीला क्षेत्र - नोड की मूल संरचनाएं। जेएस, ग्रीन - जेएस हीप।

जैसा कि आप देख सकते हैं, अपने चरम पर कुल netto 10 Gb और stably होल्ड है। प्रयोग के बाद, सभी मापदंडों को मूल नोड्स .js संरचनाओं को छोड़कर, उनके मूल मूल्यों पर लौटा दिया जाता है। आइए नीचे उन्हें वापस लें।

एक ही परीक्षण पर CPU उपयोग:

यहां सब कुछ सरल है - 8 कोर = 800%। कुल - कुल भार, सीपीयू (लगभग कुल के समान) - नोड का कुल भार। उपयोगकर्ता, एसआईएस प्रक्रियाएं - उपयोगकर्ता मोड और कर्नेल में कुल लोड, क्रमशः। 10 सेकंड की चलती औसत से लाइनें चिकनी हो जाती हैं।

इस चार्ट ने, मुझे निराश किया। भार बहुत बड़ा है, और यह स्पष्ट नहीं है कि यह किस पर खर्च किया गया है। कनेक्शन रिसेप्शन सामान्य था, लगभग 5-7 हजार कनेक्शन प्रति सेकंड, जाहिर है, यह परिदृश्य अच्छी तरह से अनुकूलित है। हालांकि, वियोग बहुत अधिक भार पैदा करता है, विशेष रूप से बड़े बैचों में (लगभग 3 मिनट के लिए ग्राफ पर, लोड का 800% जब मैंने तुरंत 400 हजार कनेक्शन तोड़ने की कोशिश की)।

आइए देखें कि इवेंट लूप कैसे व्यवहार करता है:

यह ग्राफ़ 8 श्रमिकों के लिए औसत टिक-एवी मूल्यों को दर्शाता है (दुर्भाग्य से, टिक-मैक्स को बग के कारण बहाल नहीं किया जा सकता)। पैमाना बड़े उतार-चढ़ाव को प्रतिबिंबित करने के लिए लघुगणक है। पीली रेखा 20 सेकंड की चलती औसत दिखाती है।
जैसा कि आप देख सकते हैं, औसतन, 1 मिलियन कनेक्शन के साथ, इवेंट लूप केवल 10 बार प्रति सेकंड (येलो लाइन ~ 100 एमएस) तक पहुँचा जा सकता है। यह सिर्फ अच्छा नहीं है। जब 400 हजार कनेक्शन काट दिए जाते हैं, तो औसत घटना प्रसंस्करण समय 400 एमएस तक बढ़ जाता है।

Google अपने इच्छित उद्देश्य के लिए उपयोग करने और छोटे पैमाने के कई प्रयोगों का संचालन करने के बाद, यह पता चला कि लोड का मुख्य भाग कचरा कलेक्टर के कारण होता है, जो "भारी" मार्क और स्वीप एल्गोरिथ्म (वी 8 में से दो का उपयोग करके बहुत अधिक मेमोरी इकट्ठा करने की कोशिश करता है - उनमें से दो अभी भी एक "हल्का" स्कैवेंज है) । इस व्यवहार की जिम्मेदारी Node.js और V8 के बीच की सीमा पर कहीं है, और आइडल अधिसूचना तंत्र से संबंधित है। संक्षेप में, यह V8 के लिए एक संकेत है कि अभी काम नहीं किया जा रहा है और यह कचरा साफ करने का समय है कि Node.js गाली दे रहा है, खासकर अगर JS HeapTotal> 128Mb।

नोड --nouse-idle-notification server.js

सौभाग्य से, हम इस संकेत को फ्लैग --nouse-idle-notification से जोड़कर बंद कर सकते हैं। आइए देखें कि यह हमें दूसरे टेस्ट में क्या देगा:

सबसे पहले, यह ध्यान दिया जा सकता है कि मेमोरी की खपत 1 जीबी (10%) बढ़ गई और अंतिम कनेक्शन के 5 मिनट बाद स्थिर हो गई, जो सामान्य रूप से खराब नहीं है। इसके अलावा, ग्राफ का "आरा" स्वभाव दिखाई देता है। क्यों?

आइए एक सरलीकृत परीक्षण में एक कार्यकर्ता की स्मृति खपत का ग्राफ देखें:

अब यह स्पष्ट है - लगभग 5 मिनट में, प्रत्येक कार्यकर्ता में कचरा संग्रह होता है, जो कुल मेमोरी के ग्राफ में "देखा" होता है।

हम प्रोसेसर और इवेंट लूप को देखते हैं:

खैर, यह बेहतर है! 1 मिलियन यौगिक 8 के 2 से 3 कोर से लोड होते हैं।

अब देखते हैं कि कचरा परीक्षण के बिना गरबा कलेक्टर तीसरे टेस्ट में अच्छा प्रदर्शन करते हैं या नहीं:

यह ग्राफ दर्शाता है, सबसे पहले, कि पीला क्षेत्र (Node.js मूल संरचनाएं) अभी भी लीक नहीं हुआ था, लेकिन पुन: उपयोग किया गया था। दूसरे, कचरा संग्रह बेहतर हो सकता है।

नोड --nouse-idle-notification --expose-gc server.js

खैर, हम कचरा संग्रह को अपने हाथों में लेते हैं। नोड को ध्वज के साथ चलाएँ - "exex-gc "और कॉल gc (); चौथे टेस्ट में एक बार:

खैर, बुरा नहीं है। मेमोरी को बहुत जल्दी मुक्त किया जाता है, प्रोसेसर नियंत्रण में है, लेकिन एक मिनट में हमारे पास टिक-एवी फट होता है। मुझे लगता है कि यह एक अच्छा समझौता है।

आगे क्या है?

सबसे पहले, स्वतंत्र परीक्षण द्वारा परिणामों की पुष्टि करना आवश्यक है। मैंने इसे सरल बनाने के लिए सब कुछ किया। कृपया, यदि आपके पास एक अच्छा मशीन बेकार है, तो अपने तरीके से जाने की कोशिश करें - यह बहुत दिलचस्प है।

दूसरे, यह स्पष्ट है कि यह बेंचमार्क वास्तविकता से बहुत दूर है। एक दिलचस्प वास्तविक एप्लिकेशन के रूप में, जैबर सर्वर के एनालॉग का निर्माण करना और उसी संस्करणों पर परीक्षण करना अच्छा होगा।
किसी भी मामले में, मुझे उम्मीद है कि वर्तमान रूपरेखा Node.js और V8 डेवलपर्स को आगे के अनुकूलन में मदद करेगी।

तीसरा, यह पता लगाने के लिए और प्रयोगों की आवश्यकता है:

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

Node.js पर एक साथ मिलियन कनेक्शन