python - tornado vs wsgi(con gunicorn)

uwsgi

Question

Leí this sobre Tornado:

Por otro lado, si ya tiene una aplicación WSGI y desea ejecutarla en un tornado.httpserver.HTTPServer muy rápido, envuélvalo con tornado.wsgi.WSGIContainer. Pero tienes que tener cuidado. Debido a que su aplicación original no está preparada para un servidor asíncrono y generará una gran cantidad de IO / computación, bloqueará otras solicitudes mientras genera una respuesta (se aceptarán y almacenarán más solicitudes en búfer pero se pondrán en cola para su posterior manejo).

Y Guincorn dice:

''un servidor HTTP WSGI de Python para UNIX. Es un modelo de trabajador pre-tenedor portado desde el proyecto Unicorn de Ruby.

1. ¿Entonces Gunicorn generará un proceso de trabajo para manejar la solicitud?
2. ¿Una solicitud concurrente por trabajador?
3. ¿Mientras que tornado usará epoll o kqueue para hacer el trabajo en un proceso (sin proceso maestro / trabajador)?
4. Entonces, si uso la llamada de bloqueo (como requests.get en la función obtener / enviar del controlador), ¿esto bloqueará toda la gestión de solicitudes o solo la solicitud actual que se está manejando?

Answer 1

Si está ejecutando una aplicación WSGI sobre Tornado, entonces no hay una gran diferencia entre Tornado y gunicorn en tanto que nada más puede suceder siempre que la solicitud de WSGI sea manejada por la aplicación en un proceso específico. . En el caso de Gunicorn porque solo tiene una solicitud de manejo de subprocesos y en el caso de Tornado porque el bucle de evento principal nunca se ejecutará durante ese tiempo para manejar cualquier solicitud concurrente.

En el caso de Tornado en realidad hay también un peligro oculto.

Para Gunicorn, debido a que solo hay un subproceso de solicitud, el proceso de trabajo solo aceptará una solicitud web a la vez. Si hay solicitudes concurrentes que llegan al servidor, serán manejadas por cualquier otro proceso de trabajo disponible, ya que todos comparten el mismo socket de escucha.

Sin embargo, con Tornado, la naturaleza asíncrona de la capa bajo la aplicación WSGI significa que un solo proceso puede aceptar más de una solicitud al mismo tiempo. Inicialmente se intercalarán a medida que se leen los encabezados y el contenido de la solicitud, que Tornado lee previamente en la memoria antes de llamar a la aplicación WSGI. Cuando se haya leído todo el contenido de la solicitud, el control se entregará a la aplicación WSGI para manejar esa solicitud. Mientras tanto, la solicitud simultánea que se maneja mediante el mismo proceso para el que aún no se han leído los encabezados y el contenido de la solicitud, se bloqueará mientras la aplicación WSGI tarde en manejar la primera solicitud.

Ahora, si solo tiene un proceso de Tornado, esto no es un gran problema ya que las solicitudes se serializarían de todos modos, pero si está usando el modo de trabajador tornado de Gunicorn para habilitar múltiples procesos de trabajo de Tornado que comparten los mismos contactos de oyentes, esto puede ser bastante malo. Esto se debe a la naturaleza codiciosa de los procesos individuales que resultan de la capa asíncrona, lo que significa que las solicitudes se pueden bloquear en un proceso cuando podría haber otro proceso de trabajo que podría haberlo manejado.

En resumen, para un solo proceso del servidor web de Tornado, está bloqueado y solo puede manejar una solicitud a la vez. En Gunicorn puede tener varios procesos de trabajo para permitir que las solicitudes se manejen simultáneamente. Utilice una configuración de proceso múltiple con Tornado y corre el riesgo de que se bloqueen las solicitudes.

Por lo tanto, Tornado puede ser bastante bueno para aplicaciones WSGI personalizadas muy pequeñas en las que no hacen mucho, por lo que la respuesta es muy rápida, pero puede sufrir cuando tiene solicitudes de ejecución largas que se ejecutan bajo una aplicación WSGI de bloqueo. Por lo tanto, Gunicorn será mejor ya que tiene la capacidad adecuada para manejar solicitudes concurrentes. Sin embargo, dado que Gunicorn tiene un solo hilo y necesita múltiples procesos de trabajo, utilizará mucha más memoria.

Por lo tanto, ambos tienen ventajas y desventajas y, en algunos casos, puede ser mejor usar un servidor WSGI que ofrezca concurrencia mediante subprocesamiento múltiple y procesos de trabajo múltiples. Esto le permite manejar solicitudes concurrentes, pero no soplar el uso de la memoria a través de la necesidad de muchos procesos de trabajo. Al mismo tiempo, debe equilibrar el número de subprocesos por proceso con el uso de múltiples procesos para no sufrir excesivamente los efectos de la GIL en una aplicación con gran cantidad de CPU.

Las opciones para los servidores WSGI con capacidades de subprocesamiento múltiple son mod_wsgi, uWSGI y camarera. Para la camarera, usted está limitado a un solo proceso de trabajo.

En resumen, el mejor servidor WSGI realmente depende mucho de los aspectos específicos de su aplicación web. No hay un servidor WSGI que sea el mejor en todo.