Letzte Woche wurde eine Übersetzung eines zwei Jahre alten Artikels veröffentlicht. Leistungsanalyse von WSGI-Servern: Teil Zwei , in dem uWSGI zu Unrecht getäuscht wurde.

Es ist dringend erforderlich, die Tests erneut zu überprüfen!

Ziele

Ich benutze uWSGI schon lange und möchte zeigen, dass es nicht so schlimm ist, wie in den Tests 2016 beschrieben.
Anfangs wollte ich nur die Tests reproduzieren und herausfinden, was mit uWSGI nicht stimmt.
Es gibt keine Versionen der im Code verwendeten Pakete und Module.

Daher funktioniert es nicht, Tests durchzuführen und ähnliche Ergebnisse zu erzielen.
Als nächstes möchte ich Tests durchführen und die Ergebnisse in den Grafiken vergleichen.
Auf Wunsch der Leser wurde die NginX-Einheit hinzugefügt.

Schritte

wrk 4.1.0

Spezifikationen finden , patchen , sammeln
Informationen zu readme.rd hinzugefügt.

Docker-Statistiken

Seit 2 Jahren hat sich die statistische Ausgabe geändert.

Eine zweite NAME Spalte wurde hinzugefügt, wodurch der Statistik-Parser beschädigt wurde.

Um in zwei Jahren nicht auf ein ähnliches Problem zu stoßen, verwenden wir die formatierte Ausgabe:

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

Dementsprechend werden wir den Parser-Code ein wenig vereinfachen.

Debian

Das neueste Debian-Image ist jetzt Version 9.5 . Zeigen Sie dies in Dokerfile an:

 - FROM debian + FROM debian:9.5 

Im April 2016 war die neueste Version 8.4

Trotzdem blieb Apache fast gleich: Jetzt ist die Version von Apache 2.4.25 und 2016 Apache 2.4.10.

cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi

Es macht keinen Sinn zu sagen, dass sich die Module geändert haben.
Geben Sie die aktuelle Version an:

 - 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 

Was macht der Tornado dort, wo wird die wsgi-Datei zum Starten des Tornados gestartet? Löschen Sie das Artefakt.
Es wäre nicht schlecht, dies in eine separate Anforderung.txt zu stellen, aber lassen wir es jetzt so.

cherrypy -> cheroot.wsgi

Wie oben gezeigt, ist die aktuelle Version 17.4.0.
Im April 2016 wurde wahrscheinlich die Version v5.1.0 verwendet.
Im Jahr 2017 wurden in Version 9.0 Änderungen vorgenommen, die sich auf den Serverimport auswirkten:

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

Socket-Fehler: Lesen Sie 100500

Nach den oben beschriebenen Änderungen wurde der erste vollwertige Test gestartet.
Die Ergebnisse waren gut: uwsgi produzierte nicht 3 ... 200, sondern 7500 ... 5000 Anfragen pro Sekunde.
Bei einer detaillierten Untersuchung der erhaltenen Grafiken stellte sich jedoch heraus, dass wrk alle Antworten als Lesefehler erkannte.

Nach dem Überprüfen von Dutzenden von uwsgi-Startschlüsseln stellte sich heraus, dass beim Einschalten von http1.1 keine Fehler aufgetreten sind: --http- keepalive und --http11-socket .
Darüber hinaus gibt der erste 7500 ... 5000 Anfragen pro Sekunde und der zweite stabile 29 Tausend!

Was hat sich im Moment in uWSGI geändert?

Es ist sehr wahrscheinlich, dass im August 2016 die Version von uWSGI 2.0.12 (20151230) verwendet wurde.
Nachdem im Mai uWSGI 2.0.13 veröffentlicht wurde .

Dies war ein bedeutsames Ereignis, das jedoch das Leistungsproblem gemäß der Wrk- Version erst 2018 mit der Veröffentlichung von uWSGI 2.0.16 löste :

Backportierte HTTP / 1.1-Unterstützung (--http11-Socket) ab 2.1

Aus diesem Grund wurde uWSGI für die Verwendung mit NginX empfohlen.
Und warum dies im Rahmen des Artikels wichtig ist, lässt sich aus diesem Ticket im Jahr 2012 ablesen .

Warum waren dann solche Ergebnisse

Ich habe folgende Versionen ausprobiert:

• 2.0.12 für debian 8.4, auf den neun wird es wegen des frischen openssl nicht gehen.
• 2.0.13 ... 2.0.17 für Debian 8.4 und 9.5

Aber ich konnte keine so schlechten Ergebnisse wie 3 ... 200 Abfragen pro Sekunde erzielen.
Es wurde auf die Startlinie der Anwendung hingewiesen:

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

Wenn Sie ein Plug-In angeben, wird uwsgi aus dem Repository und nicht aus pip installiert.
Dies kann darauf hinweisen, dass der Autor nicht über die erforderliche Erfahrung mit diesem Stapel verfügt.

Daher gebe ich mehrere Möglichkeiten zu:

• Der Test jedes der uwsgi-Server wurde zu unterschiedlichen Zeiten separat durchgeführt.
• Es gab einen Konflikt zwischen der Systemversion von uwsgi und der Installation über pip.
• Die wrk-Version des Autors im Jahr 2016 hatte einige Funktionen für die Arbeit an http1.0
• uwsgi begann mit einer anderen Reihe von Optionen
• Sonderanfertigung, Figuren von der Decke.

Was sind die Ergebnisse jetzt

uWSGI in den Charts sind mehrere:
Die ersten beiden uWSGI und uWSGIbase (v2.0.17.1) wurden in einem langen Test mit ihren Konkurrenten mit den folgenden Parametern ausgeführt:
--http11 :9808 --processes 5 --threads 2 --enable-threads .
--http11 :9808 --processes 5 .
Wie die Praxis gezeigt hat, gibt es für einen Dummy-Anwendungstest KEINEN qualitativen Unterschied.

Und separat die uWSGI-Version 2016:
uWSGI-v2.0.12th-old und uWSGI-v2.0.12nt-old - jeweils v2.0.12 mit und ohne Threads im Debian 8.4-Container.
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5

uWSGI belegt den 2. Platz, ohne die Ergebnisse mit zunehmender Belastung zu reduzieren.
An dritter Stelle steht die NginX-Einheit.

Im Low-Segment ist uWSGI-v2.0.12 auch bei steigender Last das Beste.

Hier sehen wir, wie die Einheit nicht ihre beste Seite zeigte.

uWSGI und CherryPy sind zweifellos Gewinner der Latenz.

Dieses Bild ähnelt 2016.

Hier sehen wir, wie alt uWSGI mit zunehmender Last Speicherplatz verbraucht hat.
Das Gerät erhöht auch linear den Speicherverbrauch.

Und das neue uWSGI, gunicorn, mod_wsgi - zuversichtlich "die Messlatte halten", und das sagt viel aus.

Die alten uWSGIs beginnen nach 300 offenen Verbindungen scharf Fehler zu machen.

Gerät und CherryPy - keine Fehler!
Björn beginnt mit 1000 Verbindungen zu spenden.
Aber mit der neuen uWSGI-Verrücktheit, die 200 Verbindungen startet, erhalten wir 50 Fehler und die Anzahl steigt nicht mehr an. Dieser Punkt erfordert eine detaillierte Prüfung.

Alle Daten werden hier gesammelt .
Alle Codeänderungen sind in RP sichtbar.

Schlussfolgerungen

uWSGI ist nicht so schlecht oder sogar sehr gut!
Wenn Ihnen die WRK-Testergebnisse nicht gefallen, verwenden Sie andere Tools.