Este artículo es una traducción del artículo de Kevin Goldberg "Introducción a los servidores Python WSGI: Parte 1" blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 con pequeñas adiciones del traductor
Una breve historia de los servidores WSGI Python
Los servidores
WSGI aparecieron porque los servidores web en ese momento no podían interactuar con las aplicaciones escritas en Python.
El WSGI (
pronunciado "whiz-gee" con una "g" sólida ) fue desarrollado por Philip J. Ebi (junto con Ian Biking y otros) a principios de la década de 2000. El módulo Apache, conocido como
mod_python , desarrollado por Grigory Trubetskoy a finales de los 90, procesaba en ese momento la mayoría de las aplicaciones de Python. Sin embargo,
mod_python no
era una especificación oficial. Simplemente se creó para que los desarrolladores puedan ejecutar código Python en el servidor. Desafortunadamente, este enfoque no era seguro y los desarrolladores comenzaron a buscar una nueva solución.
WSGI (Web-Server Gateway Interface) es un descendiente de
CGI (Common Gateway Interface). Cuando la web comenzó a evolucionar,
CGI creció debido al soporte de una gran cantidad de idiomas y la falta de otras soluciones. Sin embargo, esta solución fue lenta y limitada.
WSGI se desarrolló como una interfaz para enrutar solicitudes de servidores web (Apache, Nginx, etc.) a aplicaciones web.
Servidor y aplicación web
En el caso más simple,
WSGI consta de dos entidades principales:
- Servidor web ( Nginx, Apache , etc.);
- Una aplicación web escrita en Python.
Principio de funcionamiento:
El servidor web ejecuta el código y envía la información y la función de devolución de llamada asociada con la solicitud http a la aplicación web. Luego, se procesa la solicitud en el lado de la aplicación y se envía una respuesta al servidor web.
Periódicamente, entre el servidor web y la aplicación web, existen una o más capas intermedias. Tales capas permiten, por ejemplo, el equilibrio entre múltiples aplicaciones web y el preprocesamiento (preprocesamiento) del contenido entregado.
Aquí hay ejemplos de marcos que admiten WSGI:
¿Por qué WSGI?
Puede preguntar:
"OK, pero ¿por qué WSGI?" . Hay varias razones para esto:
- Los servidores WSGI fueron diseñados para manejar muchas solicitudes a la vez. Y los marcos no están diseñados para manejar miles de solicitudes y no dan una decisión sobre la mejor manera de enrutarlos (solicitudes) desde el servidor web.
- WSGI acelera el desarrollo de aplicaciones web escritas en Python. Si utiliza un marco (Django u otra cosa) en el desarrollo de su aplicación web, no necesita preocuparse por cómo su infraestructura particular utiliza el estándar WSGI .
- WSGI le brinda la flexibilidad de modificar los componentes de la pila web sin cambiar la aplicación que funciona con WSGI .
Los servidores
WSGI están disponibles en varias variaciones. Algunos están dirigidos a una solución fullstack, mientras que otros son adecuados para marcos específicos. Por ejemplo,
Gunicorn trabaja con
Django desde el primer momento. Aquí hay una mirada más cercana a los seis servidores WSGI en el mercado hoy:
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy y
Gunicorn .
Bjoern
Bjoern es un servidor WSGI asíncrono escrito en C. Escrito desde cero para ser pequeño y rápido, fue desarrollado usando
http_parser de Ryan Dahl (creador de Node.js) y el
bucle de eventos
Libev de Mark Lehmann.
Con un tamaño de descarga de solo 18 KB, consta de menos de 800 líneas de código.
Ocupa menos de 1 MB de RAM y no usa
corutinas ni hilos.
Bjoern es totalmente compatible con
WSGI y es considerado uno de los servidores
WSGI de más alto rendimiento.
Bjoern admite conexiones persistentes y puede unirse a sockets Unix o direcciones TCP.
Bjoern se considera más rápido que Gunicorn y menos hinchado que
uWSGI y
Meinheld . Uno de los inconvenientes de este servidor es la falta de documentación normal con ejemplos claros.
uWSGI
uWSGI fue desarrollado por
Unbit (Italia) con el objetivo de convertirse en una solución fullstack capaz de crear servicios de alojamiento. Lleva el nombre del estándar
WSGI y se creó como un complemento para uno de los proyectos de la compañía.
Un proyecto amplio y en constante evolución,
uWSGI le permite hacer mucho más que aplicaciones de alojamiento web. Muchos encuentran que
uWSGI es una herramienta poderosa, mientras que otros lo encuentran algo hinchado. A partir de la versión 2.0, uWSGI también admite el lanzamiento de aplicaciones web en los idiomas Lua, Perl, Ruby y otros.
mod_wsgi
mod_wsgi , un módulo de servidor HTTP Apache desarrollado por Graham Dumpleton (anteriormente uno de los desarrolladores de
mod_python ), proporciona la interfaz
WSGI para aplicaciones web. Compatible con las versiones de lenguaje Python2 y Python3. Creado como una alternativa a otras soluciones para integrar aplicaciones web como
CGI ,
FastCGI y
mod_python . Se puede instalar como un módulo Apache o mediante
mod_wsgi express . El segundo método simplifica la instalación para los desarrolladores de Python que no están tan familiarizados con Apache. Otros beneficios:
• No necesita privilegios de root con una instalación completa.
• Se crea un entorno local, que reduce el riesgo de impacto negativo en los entornos existentes.
El desarrollo de
mod_wsgi como proyecto puede parecer lento debido al hecho de que el módulo es desarrollado por un desarrollador. Otra desventaja es que la documentación actualmente está mal organizada y puede estar desactualizada.
Actualmente, el enfoque está en simplificar la implementación de Apache usando
mod_wsgi en entornos que usan
Docker .
Meinheld
Creado por Yutaka Matsubara,
Meinheld es un servidor compatible con
WSGI que aprovecha la potencia de
picoev y
greenlet para realizar E / S asincrónicas. Se puede usar con un servidor HTTP independiente o mediante
Gunicorn .
Meinheld tiene una dependencia en un componente de terceros llamado greenlet.
El repositorio de código fuente se encuentra en
GitHub .
Meinheld admite sockets web e incluye varios
parches de mono sobre otros módulos para una funcionalidad mejorada.
Cherrypy
CherryPy : más conocido como un marco minimalista de Python para escribir aplicaciones web,
CherryPy también viene con un servidor web agrupado de hilos WSGI y soporte para el protocolo HTTP / 1.1. El equipo de desarrollo de
CherryPy describe su servidor web como un servidor HTTP de alta velocidad y agrupación de hilos listo para producción. El tiene:
• Configuración rápida y fácil;
• escalabilidad;
• Una solución pequeña y fácil de usar para sus aplicaciones Python;
• Soporte SSL.
CherryPy se distingue de los servidores
WSGI más conocidos por su facilidad de uso y la conveniencia del desarrollador. Puede escribir una pequeña aplicación web en pocos minutos ejecutándola en varios procesos y creando solo un archivo llamado server.py. Al combinar
CherryPy con Nginx como servidor proxy, obtiene una forma confiable de servir sus aplicaciones web.
CherryPy fue creado por Remy Delon. Quería crear una estructura que fuera lo más cercana posible a los
principios fundamentales del desarrollo en Python .
Gunicorn
Gunicorn es un
servidor WSGI diseñado para su uso en sistemas UNIX. El nombre es una versión resumida y combinada de las palabras "Green Unicorn". Hay un unicornio verde en el sitio del proyecto.
Gunicorn ha sido portado del proyecto Unicorn de Ruby. Es relativamente rápido, requiere muchos recursos, es fácil de iniciar y funciona con una amplia gama de marcos web.
El equipo de desarrollo recomienda usar
Gunicorn junto con Nginx, donde Nginx se usa como servidor proxy.
Conclusión
En este artículo, se
analizaron los seis servidores WSGI más populares en este momento:
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy y
Gunicorn . Qué servidor usar para usted depende de las condiciones y requisitos de su aplicación. La siguiente parte analizará el rendimiento de estos seis servidores WSGI.