🕊️ 🔌 🐬 FreeBSD में HTTP सर्वर (C / C ++) के बेंचमार्क 🐉 👂🏽 ⏲️

हमने सात सी / सी ++ पुस्तकालयों, साथ ही (शैक्षिक उद्देश्यों के लिए) का उपयोग करके निर्मित HTTP सर्वर कोर के प्रदर्शन की तुलना इस क्षेत्र (nginx और node.js) में अन्य तैयार किए गए समाधानों से की है।

एक HTTP सर्वर एक जटिल और दिलचस्प तंत्र है। एक राय है कि एक प्रोग्रामर जिसने अपना कंपाइलर नहीं लिखा है, मैं "कंपाइलर" को "HTTP सर्वर" से बदल दूंगा: यह एक पार्सर है, और एक नेटवर्क के साथ काम करता है, मल्टीथ्रेडिंग के साथ अतुल्यकालिक, और बहुत कुछ ...।

सभी संभावित मापदंडों पर परीक्षण (रिटर्निंग स्टैटिक्स, डायनामिक्स, विभिन्न एन्क्रिप्शन मॉड्यूल, प्रॉक्सी, आदि) एक महीने से अधिक के श्रमसाध्य कार्य हैं, इसलिए कार्य को सरल बनाया गया है: हम कोर के प्रदर्शन की तुलना करेंगे। HTTP सर्वर का मूल (किसी भी नेटवर्क अनुप्रयोग की तरह) सॉकेट ईवेंट मैनेजर और उन्हें संसाधित करने के लिए कुछ प्राथमिक तंत्र (थ्रेड, प्रोसेस, आदि के पूल के रूप में कार्यान्वित) है। इसमें HTTP पैकेट पार्सर और प्रतिक्रिया जनरेटर भी शामिल है। पहली नज़र में, सब कुछ अतुल्यकालिक घटनाओं (चयन, एपोल, आदि) के प्रसंस्करण के लिए एक विशेष प्रणाली तंत्र की क्षमताओं का परीक्षण करने के लिए नीचे आना चाहिए, उनके मेटा-रैपर (libev, boost.asio, आदि) और ओएस कर्नेल, हालांकि, एक विशिष्ट कार्यान्वयन। एक टर्नकी समाधान के रूप में प्रदर्शन में एक महत्वपूर्ण अंतर देता है।

मैंने libv पर HTTP सर्वर के अपने संस्करण को लागू किया। बेशक, कुख्यात rfc2616 की आवश्यकताओं के एक छोटे सबसेट के लिए समर्थन लागू किया गया है (यह संभावना नहीं है कि कम से कम एक HTTP सर्वर इसे पूरी तरह से लागू करता है), केवल इस परीक्षण के प्रतिभागियों के लिए आवश्यकताओं को पूरा करने के लिए आवश्यक न्यूनतम,

8000 वें बंदरगाह पर अनुरोधों को सुनें;
जाँच विधि (GET);
अनुरोध (/ उत्तर) में पथ की जांच करें;

उत्तर में होना चाहिए:

             HTTP / 1.1 200 ठीक है
             सर्वर: बेंच
             कनेक्शन: जीवित रखें
             सामग्री-प्रकार: पाठ / सादा
             कंटेंट-लंबाई: 2
             42

किसी भी अन्य तरीके से पथ - एक उत्तर त्रुटि कोड 404 (पृष्ठ नहीं मिला) के साथ लौटाया जाना चाहिए।

जैसा कि आप देख सकते हैं - कोई एक्सटेंशन नहीं, डिस्क पर फ़ाइल एक्सेस, गेटवे इंटरफेस आदि। - सब कुछ अधिकतम सरलीकृत है।
_{उन मामलों में जहां सर्वर को-ज़िंदा कनेक्शन का समर्थन नहीं करता है (वैसे, केवल cpp-netlib को इससे अलग किया गया था), क्रमशः परीक्षण किया गया था।} _मोड।

प्रागितिहास

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

क्या अपनी साइकिल को फिर से बनाना या मौजूदा समाधानों का उपयोग करना इसके लायक है?
अत्यधिक भरी हुई परियोजनाओं के लिए नोड.जेएस उपयुक्त है? यदि ऐसा है, तो सी ++ कोड के मोटे को बाहर फेंक दें और जेएस को 30 लाइनों में सब कुछ फिर से लिखें।

उदाहरण के लिए, कम महत्वपूर्ण प्रश्न थे, क्या HTTP रखने से प्रदर्शन प्रभावित होता है? (एक साल बाद, जवाब यहां दिया गया था - यह प्रभावित करता है, और बहुत महत्वपूर्ण है)।

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

ट्रेनिंग

लोहा

प्रोसेसर: CPU: AMD FX (tm) -8120 आठ-कोर प्रोसेसर
नेटवर्क: लोकलहोस्ट (क्यों देखें - TODO)

मुलायम

OS: FreeBSD 9.1-RELEASE-p7

ट्यूनिंग
आमतौर पर, नेटवर्क अनुप्रयोगों के लोड परीक्षण में, यह सेटिंग्स के निम्नलिखित मानक सेट को बदलने के लिए प्रथागत है:

/etc/sysctl.conf

kern.ipc.somaxconn = 65535
net.inet.tcp.blackhole = 2
net.inet.udp.blackhole = 1
net.inet.ip.portrange.randomized = 0
net.inet.ip.portrange.first = 1024
net.inet.ip.portrange.last = 65535
net.inet.icmp.icmplim = 1000

/boot/loader.conf

kern.ipc.semmni = 256
kern.ipc.semmns = 512
kern.ipc.semmnu = 256
kern.ipc.maxsockets = 999999
kern.ipc.nmbclusters = 65535
kern.ipc.somaxconn = 65535
kern.maxfiles = 999999
kern.maxfilesperproc = 999999
kern.maxvnodes = 999999
net.inet.tcp.fast_finwait2_recycle = 1

हालांकि, मेरे परीक्षण में उन्होंने प्रदर्शन में वृद्धि नहीं की, और कुछ मामलों में एक महत्वपूर्ण मंदी भी हुई, इसलिए अंतिम परीक्षणों में सिस्टम में सेटिंग्स में कोई बदलाव नहीं किया गया (यानी सभी डिफ़ॉल्ट सेटिंग्स, सामान्य कर्नेल)।

प्रतिभागियों

पुस्तकालय

पहला नाम	संस्करण	घटनाओं	जिंदा समर्थन	तंत्र
सीपीपी-netlib	0.10.1	Boost.Asio	नहीं	multithread
हाथ से बने	11/1/30	libev	हां	मल्टीप्रोसेस (प्रति प्रक्रिया एक धागा), अतुल्यकालिक
libevent	2.0.21	libevent	हां	सिंगल-थ्रेडेड *, एसिंक्रोनस
नेवला	5.0	चुनना	हां	एकल-थ्रेडेड, अतुल्यकालिक, एक सूची के साथ (अधिक)
प्याज़	0.5	libev	हां	multithread
Pion नेटवर्क लाइब्रेरी	0.5.4	Boost.Asio	हां	multithread
POCO C ++ लाइब्रेरी	1.4.3	चुनना	हां	बहु-थ्रेडेड (आने वाले कनेक्शन के लिए अलग थ्रेड), एक कतार (अधिक) के साथ

तैयार समाधान

पहला नाम	संस्करण	घटनाओं	जिंदा समर्थन	तंत्र
Node.js	0.10.17	libuv	हां	क्लस्टर मॉड्यूल (मल्टीप्रोसेसिंग)
nginx	1.4.4	epoll, चयन, kqueue	हां	मल्टी-प्रोसेस उपचार

_{* योजना "मल्टीप्रोसेस - वन प्रोसेस वन थ्रेड" के अनुसार परीक्षण किए गए}

निलंबित

पहला नाम	कारण
nxweb	केवल लिनक्स
जी वान	केवल लिनक्स (और आम तौर पर ... )
libmicrohttpd	निरंतर भार के अंतर्गत आता है
उपज	संकलन त्रुटियों
EHS	संकलन त्रुटियों
libhttpd	तुल्यकालिक, HTTP / 1.0, हेडर बदलने की अनुमति नहीं देता है
libebb	संकलन त्रुटियों, दुर्घटनाओं

क्लाइंट के रूप में हमने लाइटटैप के डेवलपर्स के एक एप्लिकेशन का उपयोग किया - वेटटीडीपी । यह मूल रूप से कैंटरफ को अधिक लचीले टूल के रूप में उपयोग करने की योजना बनाई गई थी, लेकिन यह लगातार दुर्घटनाग्रस्त हो गया। इसके अलावा, भारोत्तोलन कामेच्छा पर आधारित है, जो कि चयन के साथ कैंपर की तुलना में फ्रीबीएसडी के लिए बहुत बेहतर है। मुख्य परीक्षण स्क्रिप्ट के रूप में (संसाधन खपत, आदि की गणना के साथ भारोत्तोलक पर एक आवरण), हमने gwan-ovsky ab.c पर विचार किया, FreeBSD के लिए फिर से बनाया गया, लेकिन बाद में इसे Python (एप्लिकेशन में बेंचमार्क) पर स्क्रैच से फिर से लिखा गया।

क्लाइंट और सर्वर एक ही भौतिक मशीन पर चल रहे थे।
निम्नलिखित मानों का उपयोग चर मानों के रूप में किया गया:

सर्वर थ्रेड्स की संख्या (1, 2 और 3)
समवर्ती खुले ग्राहक अनुरोधों की संख्या (10, 100, 200, 400, 800)

प्रत्येक कॉन्फ़िगरेशन में, 20-30 पुनरावृत्तियों का प्रदर्शन किया गया, प्रति पुनरावृत्ति 2 मिलियन अनुरोध।

परिणाम

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

एकल-थ्रेडेड मोड में चलने वाले सर्वरों के लिए, निम्न परिणाम प्राप्त हुए (सर्वर / क्लाइंट स्ट्रीम संयोजनों के लिए अधिकतम मध्यस्थों को लिया गया):

जगह	पहला नाम	क्लाइंट। प्रवाह	प्रतिशत। समय		अनुरोध
जगह	पहला नाम	क्लाइंट। प्रवाह	कस्टम।	Syst।	सफल (एकांत में)	असफल (%)
1	nginx	400	10	10	101,210	0
2	नेवला	200	12	15	53,255	0
3	libevent	200	16	33	39,882	0
4	हाथ से बने	100	20	32	38,550	0
5	प्याज़	10	22	33	29,230	0
6	POCO	10	25	50	20,943	0
7	pion	10	24	83	16,526	0
8	Node.js	10	23	173	9374	0
9	सीपीपी-netlib	10	100	183	5362	0

scalability:

सिद्धांत रूप में, यदि अधिक कोर थे, तो हम उत्पादकता में एक रैखिक वृद्धि का निरीक्षण करेंगे। दुर्भाग्य से, सिद्धांत को सत्यापित करना संभव नहीं है - पर्याप्त नाभिक नहीं हैं।

स्पष्ट रूप से, nginx ने मुझे आश्चर्यचकित किया - आखिरकार, संक्षेप में यह एक तैयार-निर्मित, बहुक्रियाशील, मॉड्यूलर समाधान है, और परिणाम अत्यधिक विशिष्ट पुस्तकालयों से बेहतर परिमाण का एक क्रम है। सम्मान करें।

mongoose अभी भी नम है, संस्करण 5.0 रन-इन नहीं है, और शाखा एक सक्रिय विकास चरण में है।

cpp-netlib ने सबसे खराब परिणाम दिखाया। न केवल यह केवल एक ही था जो HTTP कीप-लिविंग कनेक्शन का समर्थन नहीं करता था, यह कहीं न कहीं बढ़ावा के आंत्र में भी दुर्घटनाग्रस्त हो गया, एक पंक्ति में सभी पुनरावृत्तियों को निष्पादित करने के लिए समस्याग्रस्त था। निश्चित रूप से, समाधान कच्चा है, प्रलेखन पुराना है। कानूनी अंतिम स्थान।

नोड.जेएस पहले से ही यहां डांटा है , मैं इतना स्पष्ट नहीं होगा, लेकिन वी 8 अभी भी देखा और देखा। यह उच्च-लोड समाधान क्या है जो पेलोड के बिना भी संसाधनों का इतनी उत्सुकता से उपभोग करता है और शीर्ष परीक्षण प्रतिभागियों की उत्पादकता का 10-20% देता है?

एचटीटीपी को चालू / बंद रखना: यदि पोस्ट में अंतर 2 बार पहुंच गया है, तो मेरे परीक्षणों में अंतर x10 तक था।

मिनिस्टैट के अनुसार सटीकता: 95.0% आत्मविश्वास पर कोई अंतर साबित नहीं हुआ।

यह करें

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

संदर्भ

तनाव-परीक्षण कैंपर, घेराबंदी, अपाचे बेंचमार्क, और सर्व - HTTP क्लाइंट्स सर्वर के लोड परीक्षण के लिए।
Httperf के साथ प्रदर्शन परीक्षण - बेंचमार्किंग पर टिप्स और ट्रिक्स ।
ApacheBench & HTTPerf - जी-वान से बेंचमार्क प्रक्रिया का विवरण।
Warp एक अन्य हाई-लोड शिकायत HTTP सर्वर, हास्केल है।

आवेदन

आवेदन में आप सभी परीक्षण पुनरावृत्तियों के स्रोत और परिणाम, साथ ही साथ HTTP सर्वर की विधानसभा और स्थापना पर विस्तृत जानकारी प्राप्त करेंगे।

FreeBSD में HTTP सर्वर (C / C ++) के बेंचमार्क