WSGI vs uWSGi com Nginx [fechado]

Alguém poderia explicar os prós / contras ao usar WSGI VS uWSGI com Nginx.

Atualmente estou construindo um servidor de produção para o site Django, que preparei, mas não consigo decidir se devo usar WSGI ou uWSGI. Você poderia explicar em detalhes o que diferencia cada configuração? Qual configuração deve escalar melhor?

desde já, obrigado

— medo_matriz
fonte

Esta postagem do blog é uma comparação muito detalhada de muitos servidores Python WSGI, com um resumo e algumas recomendações no final.

— Lowe Thiderman,

E também usa configurações para alguns servidores que são realmente duvidosos e fazem com que pareçam piores do que podem ser. É preciso ter cuidado com o que se lê nessa comparação.

— Graham Dumpleton

WSGI é uma especificação. uWSGI fornece uma implementação da especificação WSGI. Você não pode compará-los. Você só pode comparar diferentes implementações.

— Graham Dumpleton

Respostas:

101

Ok, galera essa confusão é por causa da falta de detalhes de várias fontes e da nomenclatura desses protocolos, e o que WSGI realmente é.

Resumo:

WSGI e uwsgi são protocolos, não servidores. Ele é usado para se comunicar com servidores da web para balanceamento de carga e, especialmente, para aproveitar recursos extras que o HTTP puro não pode fornecer. Até agora, o Nginx e o Cherokee implementaram esse protocolo.
uWSGI é um servidor e um dos protocolos que implementa é o WSGI (não confunda o protocolo uwsgi com o servidor uWSGI). WSGI é uma especificação Python . Existem várias implementações da especificação WSGI e se destina a ser usado para mais do que apenas servidores de aplicativos / servidores web, mas existem alguns servidores de aplicativos WSGI (ou seja, CherryPy, que também tem um servidor da web compatível com WSGI pronto para produção , se você já não estava confuso o suficiente!).
Comparar uwsgi com WSGI é comparar laranjas com maçãs.

— Derek Litz
fonte

Typo: "1. uwsgi é um protocolo, não um servidor." -> "1. WSGI é um protocolo, não um servidor."

— Aman de

Na verdade, o que escrevi para 1 está correto, mas é verdade que WSGI é um protocolo, assim como uwsgi, então ambas as declarações que você escreveu estão corretas :). Claro, sem o resto do contexto de 1. É o protocolo usado pelo servidor uWSGI. wiki.nginx.org/HttpUwsgiModule , - "Não confunda o protocolo uwsgi com o servidor uWSGI (que fala o protocolo uwsgi)"

— Derek Litz

Ah ok. Achei que você estava tentando desenhar uma contagem entre a instrução 1. "wsgi é um protocolo .." e 2. "uwsgi é um servidor que implementa o protocolo".

— Aman

@DerekLitz, Em quais servidores django roda quando fazemos python manage.py runserver?

— Piyush S. Wanare

python manage.py runserveré um servidor interno integrado ao Django. Não é apache, nginx, gunicorn ou qualquer outra coisa. django-extensionsfornece um runserver_plusque usa a estrutura Werkzeug, mas é o mais próximo possível de um servidor runserver.

— Mike DeSimone

Geralmente, é melhor executar o Python em um processo separado do seu servidor web principal. Dessa forma, o servidor da web pode ter muitos encadeamentos minúsculos que veiculam conteúdo estático muito rápido, enquanto seus processos Python separados serão grandes e pesados e cada um estará executando seu próprio interpretador Python. Tão simples WSGIé ruim, porque incha cada um de seus threads nginx com um grande interpretador Python. Usar flupor gunicornou uWSGIbehind nginxé muito melhor, porque libera o nginx para simplesmente servir conteúdo e permite que você escolha quantos encadeamentos nginx pequenos e leves executar, independentemente de sua escolha de quantos encadeamentos pesados do Python você cria para servir conteúdo dinâmico. As pessoas parecem muito felizes com gunicornno momento, mas qualquer uma dessas três opções deve funcionar bem.

Daqui para frente, também libera você para mover o Python para outro servidor quando a carga começar a ficar séria.

— Brandon Rhodes
fonte

Estou um pouco confuso com sua resposta. Não consigo ver que ele mencionou a execução de qualquer tipo de implementação WSGI dentro do nginx. Ele fez referência ao site principal wsgi.org. Sua comparação original entre WSGI e uWSGI é, portanto, um pouco boba em primeiro lugar, porque uWSGI é uma implementação da especificação WSGI. Você mesmo usou o termo WSGI genérico de uma forma confusa ao dizer que 'ele incha cada um de seus threads nginx com um grande interpretador Python'. A própria especificação WSGI não pode fazer isso, apenas as implementações podem.

— Graham Dumpleton

Poderia fazer sentido se estivéssemos comparando nginx + mod_wsgi (o módulo conectável) e nginx + uWSGI (o contêiner do servidor de aplicativos).

— clima de

Portanto, quando se trata de usar Nginx para executar aplicativos da web Python, como o mod_wsgi de Manlio Perillo é deadware e não recomendado, as boas soluções são WSGI com gunicorn ou uWSGI ou FastCGI com Flup?

— Gulbahar

Acredito que isso aqui http://flask.pocoo.org/docs/deploying/uwsgi/ é uma boa resposta para esclarecer a confusão. A questão não é boba, acontece a qualquer um que veja os dois termos e não tenha informações anteriores sobre como as coisas funcionam fora do mundo mod_PHP (por exemplo, nada contra php ou pessoas)

O site explica em termos práticos o que é necessário e qual é a diferença, além de ser um bom exemplo de implantação do nginx.

Para sua conveniência, a explicação do wiki Flask é citada aqui:

uWSGI é uma opção de implantação em servidores como nginx, lighttpd e cherokee; consulte FastCGI e contêineres WSGI autônomos para outras opções. Para usar seu aplicativo WSGI com o protocolo uWSGI, você precisará primeiro de um servidor uWSGI. uWSGI é um protocolo e um servidor de aplicativos; o servidor de aplicativos pode servir aos protocolos uWSGI, FastCGI e HTTP.

O servidor uWSGI mais popular é o uwsgi, que usaremos neste guia. Certifique-se de que ele está instalado para acompanhar.

— Abhishek Dujari
fonte