¿Alguien podría explicar los pros / contras al usar WSGI VS uWSGI con Nginx?
Actualmente estoy construyendo un servidor de producción para el sitio web de Django que he preparado pero no puedo decidir si debo ir con WSGI o uWSGI. ¿Podría explicar en detalle qué diferencia a cada configuración? ¿Qué configuración debería escalar mejor?
Esta publicación de blog es una comparación muy detallada de muchos servidores Python WSGI, con un resumen y algunas recomendaciones al final.
Lowe Thiderman
Y también usa configuraciones para algunos servidores que son realmente poco fiables y hacen que parezcan peores de lo que pueden ser. Hay que tener cuidado con lo que se lee en esa comparación.
Graham Dumpleton
25
WSGI es una especificación. uWSGI proporciona una implementación de la especificación WSGI. No puedes compararlos. Solo puede comparar diferentes implementaciones.
Graham Dumpleton
Respuestas:
100
Bien, muchachos, esta confusión se debe a la falta de detalles de varias fuentes, al nombre de estos protocolos y a lo que WSGI es en realidad.
Resumen:
WSGI y uwsgi SON protocolos, no servidores. Se utiliza para comunicarse con servidores web para equilibrar la carga y, especialmente, para aprovechar las funciones adicionales que HTTP puro no puede proporcionar. Hasta ahora, Nginx y Cherokee han implementado este protocolo.
uWSGI es un servidor y uno de los protocolos que implementa es WSGI (no confunda el protocolo uwsgi con el servidor uWSGI). WSGI es una especificación de Python . Hay varias implementaciones de la especificación WSGI y está destinada a ser utilizada para más que solo servidores de aplicaciones / servidores web, pero hay bastantes servidores de aplicaciones WSGI (es decir, CherryPy, que también tiene un servidor web compatible con WSGI listo para producción). , ¡si aún no estabas lo suficientemente confundido!).
Comparar uwsgi con WSGI es comparar naranjas con manzanas.
Error tipográfico : "1. uwsgi es un protocolo, no un servidor". -> "1. WSGI es un protocolo, no un servidor".
Aman
9
En realidad, lo que escribí para 1 es correcto, pero es cierto que WSGI es un protocolo además de uwsgi, por lo que ambas declaraciones que ha escrito son correctas :). Por supuesto, sin el resto del contexto de 1. Es el protocolo utilizado por el servidor uWSGI. wiki.nginx.org/HttpUwsgiModule , - "No confunda el protocolo uwsgi con el servidor uWSGI (que habla el protocolo uwsgi)"
Derek Litz
4
Ah bien. Pensé que estabas tratando de dibujar un contarst entre la declaración 1. "wsgi es un protocolo ..." y 2. "uwsgi es un servidor que implementa el protocolo".
Aman
2
@DerekLitz, ¿en qué servidores se ejecuta django cuando lo hacemos python manage.py runserver?
Piyush S. Wanare
python manage.py runserveres un servidor interno integrado en Django. No es apache, nginx, gunicorn ni nada más. django-extensionsproporciona un runserver_plusque usa el marco Werkzeug, pero eso es lo más parecido a un servidor que cualquier otro runserver.
Mike DeSimone
32
Por lo general, es mejor ejecutar Python en un proceso separado de su servidor web principal. De esa manera, el servidor web puede tener muchos subprocesos pequeños que sirven contenido estático muy rápido, mientras que sus procesos de Python separados serán grandes y pesados y cada uno ejecutará su propio intérprete de Python. Tan simple WSGIes malo, porque hincha cada uno de sus hilos nginx con un gran intérprete de Python. El uso flupo gunicorno uWSGIdetrás nginxes mucho mejor, debido a que libere a nginx simplemente servir contenido, y le permite elegir el número de pequeños hilos nginx luz para funcionar, independientemente de su elección de cuántos hilos Python peso pesado que abrir para servir contenido dinámico. La gente parece muy feliz gunicornen este momento, pero cualquiera de esas tres opciones debería funcionar bien.
En el futuro, también te libera para mover Python a otro servidor cuando la carga comienza a ser seria.
Estoy un poco confundido por tu respuesta. No veo que haya mencionado ejecutar ningún tipo de implementación WSGI dentro de nginx. Hizo referencia al sitio principal wsgi.org. Su comparación original entre WSGI y uWSGI es un poco tonta en primer lugar porque uWSGI es una implementación de la especificación WSGI. Usted mismo ha utilizado el término WSGI genérico de una manera confusa al decir que "hincha cada uno de sus hilos nginx con un gran intérprete de Python". La especificación WSGI en sí misma no puede hacer eso, solo las implementaciones pueden hacerlo.
Graham Dumpleton
1
Podría tener sentido si estuviéramos comparando nginx + mod_wsgi (el módulo conectable) y nginx + uWSGI (el contenedor del servidor de aplicaciones).
clima
Entonces, cuando se trata de usar Nginx para ejecutar aplicaciones web de Python, dado que mod_wsgi de Manlio Perillo es un software inactivo y no se recomienda, las buenas soluciones son WSGI con gunicorn o uWSGI, o FastCGI con Flup.
Gulbahar
19
Creo que esto aquí mismo http://flask.pocoo.org/docs/deploying/uwsgi/ es una buena respuesta para aclarar la confusión. La pregunta no es tonta, le sucede a cualquiera que vea los dos términos y no tenga información previa sobre cómo funcionan las cosas fuera del mundo mod_PHP (por ejemplo, nada contra php o la gente)
El sitio hace bien en explicar en términos prácticos qué se necesita y cuál es la diferencia, así como un buen ejemplo de implementación para nginx.
Para mayor comodidad, aquí se cita la explicación de Flask wiki:
uWSGI es una opción de implementación en servidores como nginx, lighttpd y cherokee; consulte FastCGI y Standalone WSGI Containers para conocer otras opciones. Para usar su aplicación WSGI con el protocolo uWSGI, primero necesitará un servidor uWSGI. uWSGI es tanto un protocolo como un servidor de aplicaciones; el servidor de aplicaciones puede servir protocolos uWSGI, FastCGI y HTTP.
El servidor uWSGI más popular es uwsgi, que usaremos para esta guía. Asegúrese de tenerlo instalado para seguir adelante.
Respuestas:
Bien, muchachos, esta confusión se debe a la falta de detalles de varias fuentes, al nombre de estos protocolos y a lo que WSGI es en realidad.
Resumen:
fuente
python manage.py runserver?python manage.py runserveres un servidor interno integrado en Django. No es apache, nginx, gunicorn ni nada más.django-extensionsproporciona unrunserver_plusque usa el marco Werkzeug, pero eso es lo más parecido a un servidor que cualquier otrorunserver.Por lo general, es mejor ejecutar Python en un proceso separado de su servidor web principal. De esa manera, el servidor web puede tener muchos subprocesos pequeños que sirven contenido estático muy rápido, mientras que sus procesos de Python separados serán grandes y pesados y cada uno ejecutará su propio intérprete de Python. Tan simple
WSGIes malo, porque hincha cada uno de sus hilos nginx con un gran intérprete de Python. El usoflupogunicornouWSGIdetrásnginxes mucho mejor, debido a que libere a nginx simplemente servir contenido, y le permite elegir el número de pequeños hilos nginx luz para funcionar, independientemente de su elección de cuántos hilos Python peso pesado que abrir para servir contenido dinámico. La gente parece muy felizgunicornen este momento, pero cualquiera de esas tres opciones debería funcionar bien.En el futuro, también te libera para mover Python a otro servidor cuando la carga comienza a ser seria.
fuente
Creo que esto aquí mismo http://flask.pocoo.org/docs/deploying/uwsgi/ es una buena respuesta para aclarar la confusión. La pregunta no es tonta, le sucede a cualquiera que vea los dos términos y no tenga información previa sobre cómo funcionan las cosas fuera del mundo mod_PHP (por ejemplo, nada contra php o la gente)
El sitio hace bien en explicar en términos prácticos qué se necesita y cuál es la diferencia, así como un buen ejemplo de implementación para nginx.
Para mayor comodidad, aquí se cita la explicación de Flask wiki:
fuente