tutorial - wsgi python flask
¿Por qué debería usar WSGI? (6)
Entonces, ¿por qué debería cambiar a eso? ¿Cuales son los beneficios?
Por lo general, si tiene un servidor web como NGINX o Apache, debe habilitar los módulos (aunque la configuración de los módulos en ambos casos es diferente).
WSGI es un estándar descrito en PEP 3333 y, básicamente, proporciona una interfaz estándar entre aplicaciones web escritas en Python y servidores web.
Eso significa que WSGI le da portabilidad a su aplicación web de Python a través de muchos servidores web diferentes, sin ninguna configuración adicional en su NGINX, Apache, etc.
Además de eso, un servidor WSGI puede ofrecerle muchas funcionalidades con más flexibilidad, en comparación con un servidor web. Gunicorn , proporciona una gran cantidad de características como:
- Número de hilos de trabajo para manejar solicitudes
- Número máximo de clientes simultáneos.
- Número máximo de conexiones pendientes.
- Limite el tamaño permitido de un campo de encabezado de solicitud HTTP.
- Número máximo de solicitudes que un trabajador procesará antes de reiniciar.
Here hay un documento completo sobre las opciones soportadas por Gunicorn.
¿Es difícil, y la curva de aprendizaje vale la pena?
Como administrador del sistema, no es necesario que comprenda todos los detalles sobre el estándar, pero como desarrollador de software, es posible que tenga que entender un poco más, que simplemente hacer pip install gunicorn y demás.
Referencias
He estado usando mod_python por un tiempo, leo más y más artículos sobre lo bueno que es WSGI, sin entender realmente por qué.
Entonces, ¿por qué debería cambiar a eso? ¿Cuales son los beneficios? ¿Es difícil, y la curva de aprendizaje vale la pena?
La mayoría de los frameworks de Python implementan wsgi. Hay mod_wsgi para apache y un módulo SCGI / FastCGI / AJP + Flup para los demás. De esa manera, puede tener todas las ventajas de un proceso Python separado, sin estar atado a un servidor web.
No debería tener que volver a aprender mucho, ya que la diferencia desde la perspectiva del desarrollador es solo una pequeña envoltura y alguna configuración del servidor.
Desde una perspectiva de implementación, la diferencia es que su código de Python vive en un proceso separado del navegador web, lo que significa
a) El proceso de Python puede ejecutarse como otro usuario que no sea el servidor web. Esto puede ser valioso para la seguridad, si se usa correctamente.
b) Los procesos del servidor web no necesitan contener el tiempo de ejecución de python. Esto puede ser un gran impulso para el rendimiento si el servidor ejecuta muchas "otras" solicitudes (archivos estáticos, etc.) y algunas solicitudes de Python pesadas.
Para desarrollar aplicaciones web sofisticadas en Python, probablemente utilice un marco de desarrollo web más completo como DJango, Zope, Turbogears, etc. Como desarrollador de aplicaciones, no tiene que preocuparse mucho por WSGI. Todo lo que debe tener en cuenta es que estos marcos son compatibles con WSGI. El WSGI permite la separación del servidor web y el código de la aplicación web y un administrador del sistema puede cambiar el servidor web siempre que la aplicación web sea compatible con WSGI. Si se está desarrollando en uno de estos marcos, de todos modos estaría satisfaciendo esta condición.
Si eres un desarrollador de framework web (que está desarrollando DJango o Zope), entonces debes entender WSGI con mayor profundidad.
WSGI es la API estándar, que le permite elegir el servidor web y también colocar un canal WSGI como Repoze delante de él.
mod_wsgi vs. mod_python:
- mod_wsgi es un poco más rápido (internamente hay más C, menos Python)
- Los procesos mod_wsgi se pueden aislar de Apache, lo que mejora la seguridad / estabilidad con un menor uso de memoria [1]
- mod_python le da acceso a algunas de las partes internas de Apache
WSGI en general:
- un montón de middleware reutilizable (autenticación / autorización, cosas de sesión, almacenamiento en caché, filtrado)
- facilidad de implementación en servidores web que no sean Apache, ya sea mediante soporte nativo WSGI o flup
[1] - en comparación con un Apache preforking, que mantiene un intérprete de Python separado en cada proceso