बैलांकरों की लड़ाई

बैलेन्कर्स की लड़ाई, बैलेंसर्स / प्रॉक्सिज़ का एक लोड परीक्षण है जो वेबस्केट्स का समर्थन करता है। ये प्रौद्योगिकियां बुनियादी ढाँचे के लिए अपरिहार्य हैं।

निम्नलिखित तकनीकों का परीक्षण किया गया:

- http- प्रॉक्सी , संस्करण: 0.10.0
- HAProxy , संस्करण: 1.5-dev18 (विकास रिलीज़)
- नियंत्रण परीक्षण के लिए प्राथमिक "इको सर्वर"।

हिपाचे के बारे में संदेह था। इसे बाहर करने का कारण सरल है - यह http-प्रॉक्सी के आधार पर बनाया गया है। फिलहाल, वे परियोजना के एक कांटे का उपयोग कर रहे हैं, जिसमें प्रदर्शन से संबंधित कोई पैच नहीं हैं।

परीक्षण के लिए, 3 अलग, असंबद्ध सर्वर का उपयोग किया गया था, सभी को हर्षित पर होस्ट किया गया था ।

1. प्रॉक्सी, 512Mb, उबंटू सर्वर। इस सर्वर पर सभी प्रॉक्सी स्थापित किए गए थे। छवि: sdc: jpc: ubuntu-12.04: 2.4.0
2. WebSocket सर्वर, Node.js के साथ 512MB "स्मार्ट मशीन", जिस पर हमारा WebSocket इको सर्वर घूम रहा था। सर्वर Node.js में लिखा गया है और क्लस्टर मॉड्यूल का उपयोग करके कई कर्नेल पर चलता है। छवि: sdc: sdc: नोडज: 1.4.0
3. थोर, 512MB, पिछले एक के समान विनिर्देशों के साथ Node.js पर एक और "स्मार्ट मशीन"। इस सर्वर से हमने आवश्यक भार उत्पन्न किया। थोर वेबस्केट लोड जेनरेशन टूल है जिसे हमने विकसित किया है। यह एप्लिकेशन ओपन सोर्स वितरित किया गया है और http://github.com/observes/thor पर उपलब्ध है।

प्रॉक्सी सेटिंग्स

हमारा प्रॉक्सी सर्वर उबंटू 12.04 वाला "क्लीन" सर्वर था। सभी निर्भरताओं को कॉन्फ़िगर और स्थापित करने के लिए निम्नलिखित कदम उठाए गए हैं। यह सुनिश्चित करने के लिए कि हम नवीनतम संस्करणों के साथ काम कर रहे हैं, चलाएं:

apt-get upgrade 

निम्नलिखित निर्भरता प्रणाली में स्थापित की गई थी:
- gitub रिपॉजिटरी तक पहुंचने के लिए गिट
- स्रोत से प्रॉक्सी को संकलित करने के लिए बिल्ड-आवश्यक, अधिकांश परदे के पीछे केवल हाल ही में WebSockets या HTTPS के लिए समर्थन प्राप्त किया
- HTTPS का समर्थन करने के लिए libssl-dev की आवश्यकता होती है
- स्टड के लिए लिबेव-देव की आवश्यकता होती है, जो अविश्वसनीय है

 apt-get install git build-essential libssl-dev libev-dev 

Node.js

HTTP- प्रॉक्सी के लिए Node.js की जरूरत है। जबकि HTTP- प्रॉक्सी Node.js के नवीनतम संस्करण का उपयोग करता है, ये परीक्षण सभी निर्भरता की संगतता सुनिश्चित करने के लिए संस्करण 0.8.19 पर किए गए थे। Node.js को github के साथ क्लोन किया गया है।

 git clone git://github.com/joyent/node.git cd node git checkout v0.8.19 ./configure make make install 

यह बाइनरी एनपीएम स्थापित करता है ताकि हम इस परियोजना की निर्भरता स्थापित कर सकें। इस रिपॉजिटरी और http-प्रॉक्सी के रूट में npm इंस्टॉल रन करें और सभी निर्भरताएं अपने आप इंस्टॉल हो जाएंगी।

nginx

Nginx पहले से ही एक व्यापक सर्वर है। यह विभिन्न सर्वर बैकेंड को सम्‍मिलित करने के लिए समर्थन करता है, लेकिन WebSockets का समर्थन नहीं करता। बहुत समय पहले नहीं, इसे नगनेक्स शाखा के विकास में जोड़ा गया था। इस प्रकार, हमने नवीनतम विकास संस्करण स्थापित किया और स्रोत से संकलित किया:
कृपया ध्यान दें कि इस लेख का परीक्षण करने और लिखने के बाद, nginx 1.4.0 जारी किया गया है, जिसमें WebSockets का समर्थन है। इसलिए यदि आप इस लेख को पढ़ रहे हैं और इसे उत्पादन पर तैनात करने की योजना बना रहे हैं, तो मेरी सलाह है कि संस्करण 1.4.0 का उपयोग करें। इसके बजाय विकास संस्करण।

 wget http://nginx.org/download/nginx-1.3.15.tar.gz tar xzvf nginx-1.3.15.tar.gz cd nginx-1.3.15 ./configure --with-http_spdy_module --with-http_ssl_module \ --pid-path=/var/run/nginx.pid --conf-path=/etc/nginx/nginx.conf \ --sbin-path=/usr/local/sbin --http-log-path=/var/log/nginx/access.log \ --error-log-path=/var/log/nginx/error.log --without-http_rewrite_module 

जैसा कि आप इन विकल्पों में से देख सकते हैं, हमने SSL, SPDY को चालू किया और कुछ अन्य सेटिंग्स का उपयोग किया। अंत में, यह सामान्य विन्यास सामने आया:

 Configuration summary + PCRE library is not used + using system OpenSSL library + md5: using OpenSSL library + sha1: using OpenSSL library + using system zlib library nginx path prefix: "/usr/local/nginx" nginx binary file: "/usr/local/sbin" nginx configuration prefix: "/etc/nginx" nginx configuration file: "/etc/nginx/nginx.conf" nginx pid file: "/var/run/nginx.pid" nginx error log file: "/var/log/nginx/error.log" nginx http access log file: "/var/log/nginx/access.log" nginx http client request body temporary files: "client_body_temp" nginx http proxy temporary files: "proxy_temp" nginx http fastcgi temporary files: "fastcgi_temp" nginx http uwsgi temporary files: "uwsgi_temp" nginx http scgi temporary files: "scgi_temp" 

उसके बाद:

 make make install 

HAProxy

HAProxy पहले tcp मोड में WebSockets को प्रॉक्सी करने में सक्षम था, और अब http मोड में भी। HAProxy को HTTPS समाप्ति के लिए भी समर्थन मिला। तो फिर से हमें विकास ब्रंच स्थापित करने की आवश्यकता है।

 wget http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev18.tar.gz tar xzvf haproxy-1.5-dev18.tar.gz cd haproxy-1.5-dev18 make TARGET=linux26 USE_OPENSSL=1 make install 

टेक

हालाँकि HAProxy में SSL समाप्ति क्षमता होती है, फिर भी आमतौर पर HAProxy से पहले SSL समाप्ति के लिए स्टड का उपयोग किया जाता है। और हम इसे सत्यापित भी करना चाहते हैं।

 git clone git://github.com/bumptech/stud.git cd stud make make install 

अब जब सब कुछ स्थापित हो गया है, तो आपको कॉन्फ़िगरेशन फ़ाइलों को कॉन्फ़िगर करने की आवश्यकता है। Nginx के लिए, आप इस रिपॉजिटरी की जड़ से /etc/nginx/nginx.conf में nginx.conf को कॉपी कर सकते हैं। अन्य परदे के पीछे मक्खी पर कॉन्फ़िगर किया जा सकता है।

कर्नेल ट्यूनिंग

सभी परदे के पीछे स्थापित करने के बाद, सॉकेट्स के कुछ ट्यूनिंग की आवश्यकता होती है। मैंने इंटरनेट से यह जानकारी खींची:

 vim /etc/sysctl.conf 

और निम्न मान सेट हैं:

 # General gigabit tuning: net.core.somaxconn = 16384 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_syncookies = 1 # this gives the kernel more memory for tcp # which you need with many (100k+) open socket connections net.ipv4.tcp_mem = 50576 64768 98152 net.core.netdev_max_backlog = 2500 

बेंच मार्किंग

2 अलग-अलग परीक्षण किए जाते हैं:
1. SSL के बिना परीक्षण प्रॉक्सी सर्वर लोड करें। इस स्थिति में, हम केवल WebSockets प्रॉक्सी प्रदर्शन का परीक्षण करते हैं।
2. SSL के साथ टेस्ट प्रॉक्सी सर्वर लोड करें। असुरक्षित WebSockets का उपयोग न करें, जैसा कि उनका ब्राउज़र में बहुत बुरा संबंध है। लेकिन यहाँ प्रॉक्सी सर्वर के लिए SSL समाप्ति प्रक्रिया के दौरान अतिरिक्त लोड जोड़ा जाता है।
हमारे दो परीक्षणों के अलावा, हम विभिन्न प्रकार के यौगिकों की कोशिश करते हैं:
- 2 कि
- 5 कि
- 10 कि
और एक ही परिणाम के लिए भी:
- 20 कि
- 30 कि
प्रत्येक परीक्षण से पहले, सभी WebSocket सर्वर रीसेट हो जाते हैं, और प्रॉक्सी को फिर से व्यवस्थित किया जाता है। थोर 100 परदे के साथ एक साथ कनेक्शन की एक्स-संख्या के साथ सभी परदे के पीछे लोड करता है। प्रत्येक स्थापित कनेक्शन के लिए, एक UTF-8 संदेश भेजा और प्राप्त किया जाता है। संदेश प्राप्त होने के बाद, कनेक्शन बंद है।

लांच

टेक

 stud --config stud.conf 

HAProxy

 haproxy -f ./haproxy.cfg 

nginx

 nginx 

http प्रॉक्सी

 FLAVOR=http node http-proxy.js 

WebSocketServer

 FLAVOR=http node index.js 

परिणाम

http- प्रॉक्सी अपने नाम तक रहता है, यह अनुरोध करता है और यह काफी तेजी से करता है। लेकिन कब से यह Node.js पर आधारित है, यह बहुत मेमोरी खाती है। यहां तक ​​कि सबसे सरल नोड प्रक्रिया में 12+ एमबी मेमोरी की आवश्यकता होती है। 10k प्रश्नों के लिए, इसमें लगभग 70 MB मेमोरी लगी। नियंत्रण परीक्षण की तुलना में, HTTP प्रॉक्सी ने 5 सेकंड अधिक लिया। HTTPS, जैसा कि अपेक्षित था, सबसे धीमा परिणाम दिखा, क्योंकि Node.js SSL पर हार रहा है। और यह इस तथ्य का उल्लेख नहीं है कि, एक भारी भार के तहत होने के नाते, यह आपके मुख्य ईवेंट लूप को पूरी तरह से रोक देता है।
Http- प्रॉक्सी के लिए एक पुल अनुरोध है जो मेमोरी के उपयोग को काफी कम करता है। मैंने मैन्युअल रूप से पैच को लागू किया, और परिणामस्वरूप, खाने की स्मृति आधी हो गई। लेकिन फिर भी, पैच के बाद भी, यह नगनेक्स की तुलना में अधिक मेमोरी का उपयोग करता है, जिसे बाद में शुद्ध सी में लिखकर आसानी से समझाया गया है।
मुझे नग्नेक्स के लिए उच्च उम्मीदें थीं, और यह मुझे विफल नहीं किया। उन्होंने 10 एमबी से अधिक मेमोरी का उपयोग नहीं किया, और वास्तव में बहुत जल्दी काम किया। पहली बार जब मैंने नगनेक्स का परीक्षण किया, तो इसने भयानक प्रदर्शन दिखाया। नोड ने Nginx की तुलना में SSL के साथ और भी तेज़ी से परिणाम दिखाए, और मुझे लगा कि किसी प्रकार की त्रुटि होनी चाहिए, मुझे Nginx को कॉन्फ़िगर करने में गलत होना चाहिए। दोस्तों से कुछ सुझावों के बाद, मैंने वास्तव में विन्यास में एक पंक्ति को बदल दिया - गलत एन्क्रिप्शन सेटिंग्स थीं। Opensl s_client -connect सर्वर के साथ एक छोटा सा सेटअप और पुष्टि: आईपी सब कुछ तय किया (अब वास्तव में तेजी से RC4 एन्क्रिप्शन डिफ़ॉल्ट रूप से उपयोग किया जाता है)।
अगला HAProxy था, जिसमें NGINX के समान प्रदर्शन था, लेकिन मेमोरी की कम (7 एमबी) आवश्यकता थी। एचटीटीपीएस पर परीक्षण करते समय सबसे बड़ा अंतर था: यह बहुत धीमा था, नग्नेक्स के करीब भी नहीं था। हमें उम्मीद है कि यह तय हो जाएगा, क्योंकि अब तक हमने केवल विकास ब्रंच का परीक्षण किया है। तब मैंने Nginx के साथ एक ही गलती की, गलत तरीके से कॉन्फ़िगर किया गया एन्क्रिप्शन, जिसे मैंने HackerNews पर सही तरीके से देखा। एचटीटीपीएस के परीक्षण के अलावा, हमने दिखाए गए प्रदर्शन का परीक्षण करने के लिए इसके सामने स्टड स्थापित किया।

निष्कर्ष

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

HTTP

प्रतिनिधि	कनेक्शन	हैंडशेकन (मध्यम)	विलंबता (मध्यम)	केवल
http प्रॉक्सी	10k	293 मि	44 मि	30168 मि
nginx	10k	252 मि	16 एमएस	28433 एमएस
haproxy	10k	209 मि	18 मि	26974 एमएस
नियंत्रण	10k	189 मि	16 एमएस	25310 एमएस

विजेता : Nginx और HAProxy वास्तव में तेज़ हैं और उनके परिणाम करीब हैं।

HTTPS

प्रतिनिधि	कनेक्शन	हैंडशेकन (मध्यम)	विलंबता (मध्यम)	केवल
http प्रॉक्सी	10k	679 मि	62 मि	68670 मि
nginx	10k	470 मि	30 मि	50 180 मि
haproxy	10k	464 मि	25 मि	50058 मि
haproxy + स्टड	10k	492 मि	42 मि	52403 एमएस
नियंत्रण	10k	703 मि	65 मि	71500 मि

विजेता : Nginx और HAProxy वास्तव में तेज़ हैं और उनके परिणाम करीब हैं।

सभी परीक्षा परिणाम यहां उपलब्ध हैं: https://github.com/observes/balancerbattle/tree/master/results

जमा (योगदान)

सभी कॉन्फ़िगरेशन रिपॉजिटरी में हैं, मुझे यह जांचने में बहुत खुशी होगी कि क्या हम अपने सर्वर का बेहतर प्रदर्शन प्राप्त कर सकते हैं।