पिछले हफ्ते, दो साल पुराने एक लेख का अनुवाद प्रकाशित किया गया था। डब्ल्यूएसजीआई सर्वर: पार्ट टू का प्रदर्शन विश्लेषण , जहां यूडब्ल्यूएसजीआई को प्रसिद्धि से वंचित किया गया था।

परीक्षणों की जाँच करना तत्काल है!

लक्ष्यों

मैं लंबे समय से uWSGI का उपयोग कर रहा हूं, और मैं यह दिखाना चाहता हूं कि यह 2016 के परीक्षणों में वर्णित उतना बुरा नहीं है।
प्रारंभ में, मैं सिर्फ परीक्षणों को पुन: प्रस्तुत करना चाहता था, और यह पता लगाना था कि uWSGI में क्या गलत है।
कोड में उपयोग किए गए पैकेज और मॉड्यूल के कोई संस्करण नहीं हैं।

इसलिए, परीक्षण चलाने और समान परिणाम प्राप्त करने के लिए - यह काम नहीं करता है।
अगला मेरी खोज परीक्षणों को चलाने और ग्राफ़ पर परिणामों की तुलना करने के लिए है।
पाठकों के अनुरोध पर, NginX Unit को जोड़ा गया है।

चरणों

प्रकोप 4.1.0

चश्मा , पैच , इकट्ठा खोजें
जानकारी readme.rd में जोड़ी गई।

डॉकटर आँकड़े

2 वर्षों के लिए, आंकड़ों का आउटपुट बदल गया है।

एक दूसरा NAME कॉलम जोड़ा गया, और इसने आँकड़े पार्सर को तोड़ दिया।

दो वर्षों में एक समान समस्या का सामना न करने के लिए, हम स्वरूपित आउटपुट का उपयोग करेंगे:

 - docker stats > "$BASE/$1.$2.stats" & + docker stats --format "{{.CPUPerc}} {{.MemUsage}}" > "$BASE/$1.$2.stats" & 

और तदनुसार, हम पार्सर कोड को थोड़ा सरल करेंगे।

डेबियन

अब नवीनतम डेबियन इमेज संस्करण 9.5 है , इसे डॉकरफाइल में प्रदर्शित करें:

 - FROM debian + FROM debian:9.5 

अप्रैल 2016 में, नवीनतम संस्करण 8.4 था

फिर भी, अपाचे लगभग एक ही रहा: अब अपाचे का संस्करण 2.4.25 है, और 2016 में यह अपाचे 2.4.10 था।

चेरी टॉर्नेडो उव्सि गुनिकॉर्न बज़र्न माइनहेड mod_wsgi

यह कहने का कोई मतलब नहीं है कि मॉड्यूल बदल गए हैं।
वर्तमान संस्करण निर्दिष्ट करें:

 - RUN pip install cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi + RUN pip install cherrypy==17.4.0 \ + uwsgi==2.0.17.1 \ + gunicorn==19.9.0 \ + bjoern=2.2.3 \ + meinheld==0.6.1 \ + mod_wsgi==4.6.5 

बवंडर वहाँ क्या करता है, बवंडर फ़ाइल लॉन्च करने के लिए कहाँ है? कलाकृतियों को हटा दें।
इसे अलग आवश्यकताओं में रखना बुरा नहीं होगा। लेकिन अभी के लिए इसे इस तरह से छोड़ दें।

चेरी -> चेरूटवॉगी

जैसा कि ऊपर दिखाया गया है, वर्तमान संस्करण 17.4.0 है।
अप्रैल 2016 में, संस्करण v5.1.0 शायद इस्तेमाल किया गया था।
और 2017 में, संस्करण 9.0 में परिवर्तन हुए, जिससे सर्वर आयात प्रभावित हुआ:

 - from cherrypy import wsgiserver - server = wsgiserver.CherryPyWSGIServer( + from cheroot.wsgi import Server as WSGIServer + server = WSGIServer( 

सॉकेट त्रुटियां: 100500 पढ़ें

ऊपर वर्णित परिवर्तनों के बाद, पहला पूर्ण परीक्षण शुरू किया गया था।
परिणाम अच्छे थे: uwsgi ने 3 ... 200 का उत्पादन नहीं किया, लेकिन 7500 ... प्रति सेकंड 5000 अनुरोध।
लेकिन प्राप्त रेखांकन की एक विस्तृत परीक्षा पर, यह पता चला कि wrk ने सभी उत्तरों को पढ़ने की त्रुटियों के रूप में पाया।

दर्जनों uwsgi स्टार्टअप कुंजियों की जाँच करने के बाद, यह पता चला है कि http1.1: --http-keepalive और --http11-socket को चालू करते समय कोई त्रुटि नहीं थी।
इसके अलावा, पहला 7500 देता है ... प्रति सेकंड 5000 प्रश्न, और दूसरा स्थिर 29 हजार!

इस समय uWSGI में क्या बदलाव आया है

यह सबसे अधिक संभावना है कि अगस्त 2016 में uWSGI 2.0.12 (20151230) के संस्करण का उपयोग किया गया था।
मई के बाद, uWSGI 2.0.13 जारी किया गया था ।

यह एक महत्वपूर्ण घटना थी, लेकिन इसने 2018 तक wrk संस्करण के अनुसार प्रदर्शन की समस्या को हल नहीं किया, uWSGI 2.0.16 की रिलीज़ के साथ:

2.1 से बैक-पोर्टेड HTTP / 1.1 सपोर्ट (--http11-socket)

यही कारण है कि NWSX के साथ उपयोग के लिए uWSGI की सिफारिश की गई थी,
और लेख के ढांचे में यह महत्वपूर्ण क्यों है यह 2012 में इस टिकट से समझा जा सकता है।

फिर ऐसे परिणाम क्यों थे

मैंने निम्नलिखित संस्करणों की कोशिश की:

• डेबियन 8.4 के लिए 2.0.12, नौ पर यह ताजे खुलने के कारण नहीं जा रहा है।
• 2.0.13 ... 2.0.17 डेबियन 8.4 और 9.5 के लिए

लेकिन मुझे इस तरह के बुरे परिणाम 3 ... 200 प्रति सेकंड नहीं मिल सकते थे।
ध्यान एप्लिकेशन लॉन्च लाइन के लिए तैयार किया गया था:

uwsgi --http: 9808 --plugin python2 --wsgi-file app.py --processes ...

प्लग-इन निर्दिष्ट करना रिपॉजिटरी से uwsgi की स्थापना को इंगित करता है, न कि पाइप को।
यह इंगित कर सकता है कि लेखक को इस स्टैक के साथ आवश्यक अनुभव नहीं है।

इसलिए, मैं कई संभावनाओं को स्वीकार करता हूं:

• प्रत्येक uwsgi- सर्वर का परीक्षण अलग-अलग समय पर अलग-अलग किया गया था।
• Uwsgi के सिस्टम संस्करण के बीच कुछ संघर्ष था और पाइप के माध्यम से स्थापित किया गया था।
• 2016 में लेखक के रेक संस्करण में http1.0 पर काम करने के लिए कुछ विशेषताएं थीं
• uwsgi विकल्पों के एक अलग सेट के साथ शुरू हुआ
• कस्टम लेख, छत से आंकड़े।

अब परिणाम क्या हैं

चार्ट पर uWSGI कई हैं:
पहले दो uWSGI और uWSGIbase (v2.0.17.1) एक लंबी परीक्षा में, अपने प्रतिद्वंद्वियों के साथ, निम्न मापदंडों के साथ चलाए गए थे:
--http11 :9808 --processes 5 --threads 2 --enable-threads ।
--http11 :9808 --processes 5
जैसा कि अभ्यास से पता चला है, डमी आवेदन परीक्षण के लिए कोई गुणात्मक अंतर नहीं है।

और, अलग से, 2016 uWSGI संस्करण:
uWSGI-v2.0.12th- पुराना और uWSGI-v2.0.12nt- पुराना - क्रमशः v2.0.12 के साथ और बिना थ्रेड्स के डेबियन 8.4 कंटेनर में।
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5

UWSGI बढ़ते भार के साथ परिणामों को कम किए बिना, 2 वां स्थान लेता है।
तीसरे स्थान पर NginX Unit है।

निम्न-खंड में, लोड में वृद्धि के साथ भी uWSGI-v2.0.12 सबसे अच्छा है।

यहां हम देखते हैं कि यूनिट ने अपना सर्वश्रेष्ठ पक्ष कैसे नहीं दिखाया।

uWSGI और चेरीपी लेटेंसी में निस्संदेह विजेता हैं।

यह तस्वीर 2016 के समान है।

यहाँ हम देखते हैं कि पुराने uWSGI ने कैसे बढ़ते लोड के साथ मेमोरी को खाया।
इकाई भी स्मृति की खपत को रैखिक रूप से बढ़ाती है।

और नया uWSGI, gunicorn, mod_wsgi - आत्मविश्वास से "बार रखें", और यह बहुत कुछ कहता है।

पुराने यूडब्ल्यूएसजीआई 300 खुले कनेक्शन के बाद तेजी से त्रुटियों को प्राप्त करना शुरू करते हैं।

इकाई और चेरीपी - कोई त्रुटि नहीं!
बज़र्न 1000 यौगिकों के साथ दान करना शुरू कर देता है।
लेकिन नए यूडब्ल्यूएसजीआई अजीबता के साथ, 200 कनेक्शन शुरू करने पर, हमें 50 त्रुटियां मिलती हैं, और संख्या अब नहीं बढ़ती है। इस बिंदु पर विस्तृत विचार की आवश्यकता है।

सारा डेटा यहां एकत्र किया गया है।
सभी कोड परिवर्तन आरपी में देखे जा सकते हैं।

निष्कर्ष

uWSGI इतना बुरा नहीं है, या बहुत अच्छा है!
यदि आप WRK परीक्षा परिणामों की तरह नहीं हैं, तो अन्य टूल का उपयोग करके देखें।