La semaine dernière, une traduction d'un article de deux ans a été publiée: Analyse des performances des serveurs WSGI: Deuxième partie , où uWSGI a été privé de renommée sans le mériter.

Il est urgent de revérifier les tests!

Buts

J'utilise uWSGI depuis longtemps et je veux montrer qu'il n'est pas aussi mauvais que celui décrit dans les tests de 2016.
Au départ, je voulais juste reproduire les tests et découvrir ce qui ne va pas avec uWSGI.
Le code ne contient pas de versions des packages et modules utilisés.

Par conséquent, pour exécuter des tests et obtenir des résultats similaires, cela ne fonctionne pas.
Ensuite, je cherche à exécuter des tests et à comparer les résultats sur les graphiques.
À la demande des lecteurs, l'unité NginX a été ajoutée.

Étapes

wrk 4.1.0

Trouver des spécifications , patcher , collecter
Informations ajoutées à readme.rd.

statistiques de docker

Depuis 2 ans, la production des statistiques a changé.

Une deuxième colonne NAME été ajoutée, ce qui a brisé l'analyseur de statistiques.

Afin de ne pas rencontrer un problème similaire dans deux ans, nous utiliserons la sortie formatée:

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

Et en conséquence, nous simplifierons un peu le code de l'analyseur.

debian

Maintenant, la dernière image Debian est la version 9.5 , affichez-la dans Dokerfile:

 - FROM debian + FROM debian:9.5 

En avril 2016, la dernière version était la 8.4

Néanmoins, Apache est resté presque le même: maintenant la version d'Apache est 2.4.25, et en 2016 c'était Apache 2.4.10.

tornade cerise uwsgi gunicorn bjoern meinheld mod_wsgi

Cela n'a aucun sens de dire que les modules ont changé.
Spécifiez la version actuelle:

 - 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 

Que fait tornado là-bas, où est le lancement du fichier wsgi pour lancer tornado? Supprimez l'artefact.
Il ne serait pas mauvais de mettre cela dans un fichier requirements.txt séparé, mais pour l'instant, laissons cela de cette façon.

cherrypy -> cheroot.wsgi

Comme indiqué ci-dessus, la version actuelle est 17.4.0.
En avril 2016, la version v5.1.0 a probablement été utilisée.
Et en 2017, des changements sont survenus dans la version 9.0 , qui ont affecté l'importation du serveur:

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

Erreurs de socket: lire 100500

Après les changements décrits ci-dessus, le premier test à part entière a été lancé.
Les résultats ont été bons: uwsgi n'a pas produit 3 ... 200, mais 7500 ... 5000 requêtes par seconde.
Mais après un examen détaillé des graphiques obtenus, il s'est avéré que wrk a détecté toutes les réponses comme des erreurs de lecture.

Après avoir vérifié des dizaines de clés de démarrage uwsgi, il s'est avéré qu'il n'y avait aucune erreur lors de l'activation de http1.1: --http-keepalive et --http11-socket .
De plus, la première donne 7500 ... 5000 requêtes par seconde, et la seconde stable 29 mille!

ce qui a changé dans uWSGI en ce moment

Il est très probable qu'en août 2016, la version de uWSGI 2.0.12 (20151230) ait été utilisée.
Après, en mai, uWSGI 2.0.13 a été publié .

Ce fut un événement capital, mais il n'a pas résolu le problème de performances selon la version wrk avant 2018, avec la sortie de uWSGI 2.0.16 :

Prise en charge HTTP / 1.1 avec portage arrière (--http11-socket) à partir de 2.1

C'est pourquoi uWSGI a été recommandé pour une utilisation avec NginX,
Et pourquoi cela est important dans le cadre de l'article peut être compris à partir de ce billet en 2012.

Pourquoi alors ces résultats

J'ai essayé les versions suivantes:

• 2.0.12 pour debian 8.4, sur le neuf, il ne va pas à cause de l'opensl frais.
• 2.0.13 ... 2.0.17 pour debian 8.4 et 9.5

Mais je ne pouvais pas obtenir des résultats aussi mauvais que 3 ... 200 requêtes par seconde.
L'attention a été attirée sur la ligne de lancement de l'application:

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

La spécification d'un plug-in indique l'installation d'uwsgi à partir du référentiel, pas de pip.
Cela peut indiquer que l'auteur n'a pas l'expérience nécessaire avec cette pile.

Par conséquent, j'admets plusieurs possibilités:

• le test de chacun des serveurs uwsgi a été effectué séparément, à différents moments.
• Il y avait un conflit entre la version système d'uwsgi et celle installée via pip.
• La version wrk de l'auteur en 2016, avait quelques fonctionnalités pour travailler sur http1.0
• uwsgi a commencé avec un ensemble d'options différent
• article personnalisé, chiffres du plafond.

Quels sont les résultats maintenant

uWSGI sur les cartes sont plusieurs:
Les deux premiers uWSGI et uWSGIbase (v2.0.17.1) ont été exécutés dans un long test, avec leurs concurrents, avec les paramètres suivants:
--http11 :9808 --processes 5 --threads 2 --enable-threads .
--http11 :9808 --processes 5 .
Comme la pratique l'a montré, il n'y a AUCUNE différence qualitative pour un test d'application factice.

Et, séparément, la version uWSGI 2016:
uWSGI-v2.0.12th et uWSGI-v2.0.12nt-old - respectivement v2.0.12 avec et sans threads dans le conteneur debian 8.4.
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5

uWSGI prend la 2e place, sans réduire les résultats avec l'augmentation de la charge.
À la troisième place se trouve l'unité NginX.

Dans le segment bas, uWSGI-v2.0.12 est le meilleur, même avec une augmentation de la charge.

Ici, nous voyons comment Unit n'a pas montré son meilleur côté.

uWSGI et CherryPy sont des gagnants incontestables en matière de latence.

Cette image est similaire à 2016.

Ici, nous voyons quel âge uWSGI mangeait de la mémoire avec une charge croissante.
L'unité augmente également linéairement la consommation de mémoire.

Et le nouveau uWSGI, gunicorn, mod_wsgi - "garde la barre" en toute confiance, et cela en dit long.

Les anciens uWSGI commencent à gagner fortement en erreurs après 300 connexions ouvertes.

Unit et CherryPy - pas d'erreurs!
Bjoern commence à faire un don avec 1000 composés.
Mais avec la nouvelle bizarrerie uWSGI, commençant 200 connexions, nous obtenons 50 erreurs, et le nombre n'augmente plus. Ce point nécessite une réflexion approfondie.

Toutes les données sont collectées ici.
Toutes les modifications de code peuvent être vues dans RP .

Conclusions

uWSGI n'est pas si mal, ni même très bon!
Si vous n'aimez pas les résultats du test WRK, essayez d'utiliser d'autres outils.