Na semana passada, foi publicada uma tradução de um artigo de dois anos: Análise de Desempenho dos Servidores WSGI: Parte Dois , onde o uWSGI foi privado da fama imerecidamente.

É urgente verificar novamente os testes!

Objetivos

Uso o uWSGI há muito tempo e quero mostrar que não é tão ruim quanto descrito nos testes de 2016.
Inicialmente, eu só queria reproduzir os testes e descobrir o que havia de errado com o uWSGI.
O código não contém versões de pacotes e módulos usados.

Portanto, para executar testes e obter resultados semelhantes, não funciona.
A seguir, minha missão de executar testes e comparar os resultados nos gráficos.
A pedido dos leitores, a Unidade NginX foi adicionada.

Passos

wrk 4.1.0

Encontre especificações , corrija , colete
Informações adicionadas ao readme.rd.

estatísticas do docker

Durante 2 anos, a produção de estatísticas mudou.

Uma segunda coluna NAME foi adicionada e isso interrompeu o analisador de estatísticas.

Para não encontrar um problema semelhante em dois anos, usaremos a saída formatada:

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

E, portanto, simplificaremos um pouco o código do analisador.

debian

Agora a imagem mais recente do debian é a versão 9.5 , exiba isso no Dokerfile:

 - FROM debian + FROM debian:9.5 

Em abril de 2016, a versão mais recente era 8.4

No entanto, o Apache permaneceu quase o mesmo: agora a versão do Apache é 2.4.25 e em 2016 era o Apache 2.4.10.

cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi

Não faz sentido dizer que os módulos foram alterados.
Especifique a versão atual:

 - 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 

O que o tornado faz lá, onde está o lançamento do arquivo wsgi para o lançamento do tornado? Exclua o artefato.
Não seria ruim colocar isso em um requirements.txt diferente, mas por enquanto vamos deixar assim.

cherrypy -> cheroot.wsgi

Como mostrado acima, a versão atual é 17.4.0.
Em abril de 2016, a versão v5.1.0 provavelmente foi usada.
E em 2017, ocorreram alterações na versão 9.0 , que afetaram a importação do servidor:

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

Erros de soquete: leia 100500

Após as alterações descritas acima, o primeiro teste completo foi lançado.
Os resultados foram bons: o uwsgi não produziu 3 ... 200, mas 7500 ... 5000 solicitações por segundo.
Porém, após um exame detalhado dos gráficos obtidos, descobriu-se que o wrk detectou todas as respostas como erros de leitura.

Após verificar dezenas de chaves de inicialização do uwsgi, verificou-se que não havia erros ao ativar o http1.1: --http-keepalive e --http11-socket .
Além disso, o primeiro fornece 7500 ... 5000 consultas por segundo e o segundo estável, 29 mil!

o que mudou no uWSGI no momento

É mais provável que em agosto de 2016 a versão do uWSGI 2.0.12 (20151230) tenha sido usada.
Depois, em maio, o uWSGI 2.0.13 foi lançado .

Este foi um evento importante, mas não resolveu o problema de desempenho de acordo com a versão wrk até 2018, com o lançamento do uWSGI 2.0.16 :

Suporte HTTP / 1.1 com porta traseira (--http11-socket) da 2.1

É por isso que o uWSGI foi recomendado para uso com o NginX,
E por que isso é importante na estrutura do artigo pode ser entendido a partir desse ticket em 2012.

Por que então esses resultados

Eu tentei as seguintes versões:

• 2.0.12 para o debian 8.4, nos nove ele não vai por causa do novo openssl.
• 2.0.13 ... 2.0.17 para debian 8.4 e 9.5

Mas não consegui resultados tão ruins como 3 ... 200 consultas por segundo.
Atenção para a linha de inicialização do aplicativo:

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

A especificação de um plug-in indica a instalação do uwsgi do repositório, não do pip.
Isso pode indicar que o autor não possui a experiência necessária com essa pilha.

Portanto, admito várias possibilidades:

• O teste de cada um dos servidores uwsgi foi realizado separadamente, em momentos diferentes.
• Houve algum conflito entre a versão do sistema do uwsgi e instalada via pip.
• A versão wrk do autor em 2016, tinha alguns recursos para trabalhar no http1.0
• O uwsgi começou com um conjunto diferente de opções
• artigo personalizado, figuras do teto.

Quais são os resultados agora

O uWSGI nos gráficos é variado:
Os dois primeiros uWSGI e uWSGIbase (v2.0.17.1) foram executados em um longo teste, com seus concorrentes, com parâmetros:
--http11 :9808 --processes 5 --threads 2 --enable-threads .
--http11 :9808 --processes 5 .
Como a prática demonstrou, NÃO há diferença qualitativa para um teste de aplicação simulada.

E, separadamente, a versão uWSGI de 2016:
uWSGI-v2.0.12th-old e uWSGI-v2.0.12nt-old - respectivamente v2.0.12 com e sem threads no contêiner debian 8.4.
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5

O uWSGI ocupa o 2º lugar, sem reduzir os resultados com o aumento da carga.
Em terceiro lugar, está a Unidade NginX.

No segmento baixo, o uWSGI-v2.0.12 é o melhor, mesmo com um aumento na carga.

Aqui vemos como a Unit não mostrou seu melhor lado.

O uWSGI e o CherryPy são vencedores inquestionáveis ​​em latência.

Esta imagem é semelhante a 2016.

Aqui vemos quantos anos o uWSGI consumiu memória com o aumento da carga.
A unidade também aumenta linearmente o consumo de memória.

E o novo uWSGI, gunicorn, mod_wsgi - confiavelmente "mantém a barra", e isso diz muito.

Os uWSGIs antigos começam a obter grandes erros após 300 conexões abertas.

Unidade e CherryPy - sem erros!
Bjoern começa a doar com 1000 compostos.
Mas com a nova estranheza do uWSGI, iniciando 200 conexões, obtemos 50 erros e o número não aumenta mais. Este ponto requer consideração detalhada.

Todos os dados são coletados aqui.
Todas as alterações de código podem ser vistas no RP .

Conclusões

O uWSGI não é tão ruim ou muito bom!
Se você não gostar dos resultados do teste WRK, tente usar outras ferramentas.