في الأسبوع الماضي ، نُشرت ترجمة لمقال يبلغ من العمر عامين ، تحليل أداء خوادم WSGI: الجزء الثاني ، حيث حُرم uWSGI من الشهرة بشكل غير مستحق.

من الملح إعادة فحص الاختبارات!

الأهداف

لقد كنت أستخدم uWSGI لفترة طويلة ، وأريد أن أثبت أنه ليس سيئًا كما هو موضح في اختبارات 2016.
في البداية ، أردت فقط إعادة إنتاج الاختبارات ، ومعرفة ما هو الخطأ في uWSGI.
لا يحتوي الرمز على إصدارات من الحزم والوحدات المستخدمة.

لذلك ، لإجراء الاختبارات والحصول على نتائج مماثلة - لا يعمل.
التالي هو سعيي لإجراء الاختبارات ومقارنة النتائج على الرسوم البيانية.
بناء على طلب القراء ، تمت إضافة وحدة NginX.

خطوات

wrk 4.1.0

البحث عن المواصفات ، التصحيح ، جمع
تمت إضافة المعلومات إلى readme.rd.

إحصائيات عامل الميناء

لمدة عامين ، تغير ناتج الإحصائيات.

تمت إضافة عمود NAME ثانٍ ، مما أدى إلى كسر محلل الإحصائيات.

حتى لا نواجه مشكلة مماثلة خلال عامين ، سنستخدم المخرجات المنسقة:

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

وبناءً على ذلك ، سنبسط رمز المحلل اللغوي قليلاً.

ديبيان

الآن أحدث صورة دبيان هي الإصدار 9.5 ، اعرضها في ملف Dokerfile:

 - FROM debian + FROM debian:9.5 

في أبريل 2016 ، كان الإصدار الأخير 8.4

ومع ذلك ، ظل Apache كما هو تقريبًا: الآن إصدار Apache هو 2.4.25 ، وفي 2016 كان Apache 2.4.10.

الكرز اعصار üsgi gunicorn bjoern meinheld 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 

ماذا يفعل الإعصار هناك ، أين إطلاق ملف wsgi لإطلاق الإعصار؟ احذف القطعة الأثرية.
لن يكون من السيء وضع هذا في ملف متطلبات منفصل. لكن الآن دعنا نتركه بهذه الطريقة.

cherrypy -> cheroot.wsgi

كما هو موضح أعلاه ، الإصدار الحالي هو 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

بعد التغييرات الموضحة أعلاه ، تم إطلاق أول اختبار كامل.
كانت النتائج جيدة: üsgi لم تنتج 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 .

كان هذا حدثًا مهمًا ، لكنه لم يحل مشكلة الأداء وفقًا لإصدار wrk حتى 2018 ، مع إصدار uWSGI 2.0.16 :

دعم HTTP / 1.1 المنفذ الخلفي (--http11-socket) من 2.1

لهذا السبب تمت التوصية باستخدام UWSGI مع NginX ،
ولماذا هذا مهم في إطار المقال يمكن فهمه من تذكرة 2012 هذه.

فلماذا كانت هذه النتائج

جربت الإصدارات التالية:

• 2.0.12 لدبيان 8.4 ، على التسعة لن يكون بسبب فتح جديد.
• 2.0.13 ... 2.0.17 لدبيان 8.4 و 9.5

لكنني لم أستطع الحصول على نتائج سيئة مثل 3 ... 200 استفسار في الثانية.
تم لفت الانتباه إلى خط تشغيل التطبيق:

uwsgi --http: 9808 - python2plugin - wsgi-file app.py - عمليات ...

يشير تحديد مكون إضافي إلى تثبيت uwsgi من المستودع ، وليس نقطة.
قد يشير هذا إلى أن المؤلف ليس لديه الخبرة اللازمة مع هذا المكدس.

لذلك ، أعترف بالعديد من الاحتمالات:

• تم اختبار كل خادم من خوادم uwsgi بشكل منفصل في أوقات مختلفة.
• كان هناك بعض التضارب بين إصدار نظام uwsgi وتم تثبيته عبر النقطة.
• نسخة wrk للمؤلف في عام 2016 ، لديها بعض الميزات للعمل على http1.0
• بدأ uwsgi بمجموعة مختلفة من الخيارات
• المادة المخصصة ، والأرقام من السقف.

ما هي النتائج الآن

uWSGI على الرسوم البيانية هي عدة:
تم تشغيل أول اثنين من uWSGI و uWSGIbase (الإصدار 2.0.17.1) في اختبار طويل ، مع منافسيهما ، بالمعلمات التالية:
--http11 :9808 --processes 5 --threads 2 --enable-threads .
--http11 :9808 --processes 5 .
كما أظهرت الممارسة ، لا يوجد فرق نوعي لاختبار تطبيق وهمي.

وبشكل منفصل ، إصدار uWSGI 2016:
uWSGI-v2.0.12th-old و uWSGI-v2.0.12nt-old - على التوالي v2.0.12 مع وبدون خيوط في حاوية دبيان 8.4.
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5

تحتل uWSGI المركز الثاني ، دون تقليل النتائج مع زيادة الحمل.
في المركز الثالث هي وحدة NginX.

في الجزء المنخفض ، فإن uWSGI-v2.0.12 هو الأفضل ، حتى مع زيادة الحمل.

هنا نرى كيف لم تظهر الوحدة أفضل جانب لها.

uWSGI و CherryPy فائزان بلا شك في الكمون.

هذه الصورة شبيهة بعام 2016.

هنا نرى كيف أكلت UWSGI القديمة الذاكرة مع زيادة الحمل.
كما تزيد الوحدة خطيًا من استهلاك الذاكرة.

و uWSGI الجديدة ، gunicorn ، mod_wsgi - بثقة "حافظوا على البار" ، وهذا يقول الكثير.

تبدأ UWSGIs القديمة في اكتساب الأخطاء بشكل حاد بعد 300 اتصال مفتوح.

الوحدة و CherryPy - لا توجد أخطاء!
يبدأ Bjoern بالتبرع بـ 1000 مركب.
ولكن مع غرابة uWSGI الجديدة ، بدءًا من 200 اتصال ، حصلنا على 50 خطأ ، ولم يعد الرقم يزيد. تتطلب هذه النقطة دراسة مفصلة.

يتم جمع جميع البيانات هنا.
يمكن رؤية جميع التغييرات في التعليمات البرمجية في RP .

الاستنتاجات

UWSGI ليست سيئة للغاية ، أو حتى جيدة جدًا!
إذا لم تعجبك نتائج اختبار WRK ، فحاول استخدام أدوات أخرى.