La semana pasada, se publicó una traducción de un artículo de dos años de antigüedad Análisis de rendimiento de los servidores WSGI: Parte dos , donde uWSGI fue privado de la fama inmerecidamente.
¡Es urgente volver a verificar las pruebas!
Objetivos
He estado usando uWSGI durante mucho tiempo y quiero mostrar que no es tan malo como se describe en las pruebas de 2016.
Inicialmente, solo quería reproducir las pruebas y descubrir qué está mal con uWSGI.
No hay versiones de los paquetes y módulos utilizados en el código .
Por lo tanto, ejecutar pruebas y obtener resultados similares, no funciona.
El siguiente es mi búsqueda para ejecutar pruebas y comparar los resultados en los gráficos.
A petición de los lectores, se ha agregado la Unidad NginX.
Pasos
wrk 4.1.0
Encuentra especificaciones , parche , recolecta
Información agregada a readme.rd.
estadísticas del acoplador
Durante 2 años, la producción de estadísticas ha cambiado.
Se agregó una segunda columna NAME , y esto rompió el analizador de estadísticas.
Para no encontrar un problema similar en dos años, utilizaremos la salida formateada:
- docker stats > "$BASE/$1.$2.stats" & + docker stats --format "{{.CPUPerc}} {{.MemUsage}}" > "$BASE/$1.$2.stats" &
Y en consecuencia, simplificaremos un poco el código del analizador.
debian
Ahora la última imagen de Debian es la versión 9.5 , muestra esto en Dokerfile:
- FROM debian + FROM debian:9.5
En abril de 2016, la última versión era 8.4
Sin embargo, Apache se mantuvo casi igual: ahora la versión de Apache es 2.4.25, y en 2016 fue Apache 2.4.10.
cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi
No tiene sentido decir que los módulos han cambiado.
Especifique la versión actual:
- 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
¿Qué hace tornado allí, dónde está el lanzamiento del archivo wsgi para lanzar tornado? Eliminar el artefacto.
No sería malo poner esto en un archivo required.txt separado, pero por ahora lo dejamos así.
cherrypy -> cheroot.wsgi
Como se muestra arriba, la versión actual es 17.4.0.
En abril de 2016, probablemente se utilizó la versión v5.1.0.
Y en 2017, se produjeron cambios en la versión 9.0 , que afectaron la importación del servidor:
- from cherrypy import wsgiserver - server = wsgiserver.CherryPyWSGIServer( + from cheroot.wsgi import Server as WSGIServer + server = WSGIServer(
Errores de socket: lea 100500
Después de los cambios descritos anteriormente, se lanzó la primera prueba completa.
Los resultados fueron buenos: uwsgi no produjo 3 ... 200, pero 7500 ... 5000 solicitudes por segundo.
Pero tras un examen detallado de los gráficos obtenidos, resultó que wrk detectó todas las respuestas como errores de lectura.
Después de comprobar una docena de claves de inicio de uwsgi, resultó que no había errores al encender http1.1: --http-keepalive y --http11-socket .
¡Además, el primero da 7500 ... 5000 consultas por segundo, y el segundo estable 29 mil!
lo que ha cambiado en uWSGI en este momento
Es muy probable que en agosto de 2016 se haya utilizado la versión de uWSGI 2.0.12 (20151230).
Luego, en mayo, se lanzó uWSGI 2.0.13 .
Este fue un evento trascendental, pero no resolvió el problema de rendimiento según la versión wrk hasta 2018, con el lanzamiento de uWSGI 2.0.16 :
Soporte HTTP / 1.1 con puerto posterior (--http11-socket) desde 2.1
Es por eso que se recomendó uWSGI para usar con NginX,
Y por qué esto es importante en el marco del artículo se puede entender a partir de este boleto en 2012.
¿Por qué entonces fueron tales resultados?
Probé las siguientes versiones:
- 2.0.12 para debian 8.4, en los nueve no va a funcionar debido a la nueva apertura.
- 2.0.13 ... 2.0.17 para debian 8.4 y 9.5
Pero no pude obtener resultados tan malos como 3 ... 200 consultas por segundo.
Se llamó la atención sobre la línea de lanzamiento de la aplicación:
uwsgi --http: 9808 --plugin python2 --wsgi-file app.py --procesos ...
La especificación de un complemento indica la instalación de uwsgi desde el repositorio, no pip.
Esto puede indicar que el autor no tiene la experiencia necesaria con esta pila.
Por lo tanto, admito varias posibilidades:
- La prueba de cada uno de los servidores uwsgi se realizó por separado, en diferentes momentos.
- Hubo algún conflicto entre la versión del sistema de uwsgi y se instaló a través de pip.
- La versión wrk del autor en 2016, tenía algunas características para trabajar en http1.0
- uwsgi comenzó con un conjunto diferente de opciones
- Artículo personalizado, figuras desde el techo.
¿Cuáles son los resultados ahora?
uWSGI en los gráficos son varios:
Los dos primeros uWSGI y uWSGIbase (v2.0.17.1) se ejecutaron en una prueba larga, con sus competidores, con parámetros:
--http11 :9808 --processes 5 --threads 2 --enable-threads .
--http11 :9808 --processes 5 .
Como ha demostrado la práctica, NO existe una diferencia cualitativa para una prueba de aplicación ficticia.
Y, por separado, la versión 2016 uWSGI:
uWSGI-v2.0.12th-old y uWSGI-v2.0.12nt-old - respectivamente v2.0.12 con y sin hilos en el contenedor de Debian 8.4.
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5
uWSGI ocupa el segundo lugar, sin reducir los resultados al aumentar la carga.
En tercer lugar está la Unidad NginX.
En el segmento bajo, uWSGI-v2.0.12 es el mejor, incluso con un aumento en la carga.
Aquí vemos cómo la Unidad no mostró su mejor lado.
uWSGI y CherryPy son indudablemente ganadores en latencia.
Esta imagen es similar a 2016.
Aquí vemos cuántos años uWSGI comió memoria con una carga creciente.
La unidad también aumenta linealmente el consumo de memoria.
Y el nuevo uWSGI, gunicorn, mod_wsgi - "mantiene el listón" con confianza, y eso dice mucho.
Los viejos uWSGI comienzan a ganar errores bruscamente después de 300 conexiones abiertas.
Unidad y CherryPy: ¡sin errores!
Bjoern comienza a donar con 1000 compuestos.
Pero con la nueva rareza uWSGI, que inicia 200 conexiones, obtenemos 50 errores y el número ya no aumenta. Este punto requiere una consideración detallada.
Todos los datos se recopilan aquí.
Todos los cambios de código se pueden ver en RP .
Conclusiones
uWSGI no es tan malo, ¡ni siquiera muy bueno!
Si no le gustan los resultados de la prueba WRK, intente usar otras herramientas.