python flask wsgi gunicorn

subplot python



¿Cuántas solicitudes concurrentes recibe un solo proceso de Frasco? (4)

Estoy construyendo una aplicación con Flask, pero no sé mucho sobre WSGI y su base HTTP, Werkzeug. Cuando empiezo a servir una aplicación Flask con gunicorn y 4 procesos de trabajo, ¿esto significa que puedo manejar 4 solicitudes simultáneas?

Quiero decir solicitudes concurrentes, y no solicitudes por segundo o cualquier otra cosa.

¡Gracias!


Actualmente hay una solución mucho más simple que las ya provistas. Cuando ejecuta su aplicación solo tiene que pasar el parámetro threaded=True a la llamada app.run() , como:

app.run(host="your.host", port=4321, threaded=True)

Otra opción, según lo que podemos ver en los documentos de werkzeug , es usar el parámetro procesess , que recibe un número> 1 que indica la cantidad máxima de procesos simultáneos para manejar:

  • Enhebrado: ¿debería el proceso manejar cada solicitud en un hilo separado?
  • procesos: si es mayor que 1, maneje cada solicitud en un nuevo proceso hasta esta cantidad máxima de procesos simultáneos.

Algo como:

app.run(host="your.host", port=4321, processes=3) #up to 3 processes

Más información sobre el método run() here y la publicación del blog que me llevó a encontrar la solución y las referencias de API.


Flask procesará una solicitud por hilo al mismo tiempo. Si tiene 2 procesos con 4 hilos cada uno, son 8 solicitudes simultáneas.

Flask no genera ni administra hilos o procesos. Esa es la responsabilidad del portal WSGI (por ejemplo, gunicornio).


No, definitivamente puedes manejar más que eso.

Es importante recordar que, en el fondo, suponiendo que ejecuta una única máquina central, la CPU realmente solo ejecuta una instrucción * a la vez.

A saber, la CPU solo puede ejecutar un conjunto muy limitado de instrucciones, y no puede ejecutar más de una instrucción por ciclo de reloj (muchas instrucciones incluso toman más de 1 tilde).

Por lo tanto, la mayoría de concurrencia de la que hablamos en ciencias de la computación es concurrencia de software. En otras palabras, hay capas de implementación de software que abstraen de nosotros la CPU de nivel inferior y nos hacen pensar que estamos ejecutando código al mismo tiempo.

Estas "cosas" pueden ser procesos, que son unidades de código que se ejecutan al mismo tiempo en el sentido de que cada proceso piensa que se está ejecutando en su propio mundo con su propia memoria no compartida.

Otro ejemplo son los hilos, que son unidades de código dentro de procesos que también permiten la concurrencia.

El motivo por el cual sus 4 procesos de trabajo podrán manejar más de 4 solicitudes es que activarán subprocesos para manejar más y más solicitudes.

El límite de solicitud real depende del servidor HTTP elegido, E / S, SO, hardware, conexión de red, etc.

¡Buena suerte!

* las instrucciones son los comandos básicos que la CPU puede ejecutar. ejemplos: agregue dos números, salte de una instrucción a otra


Cuando ejecutas el servidor de desarrollo que ejecutas app.run() , obtienes un solo proceso sincrónico, lo que significa que se procesan a lo sumo 1 solicitudes a la vez.

Al pegar a Gunicorn frente a él en su configuración predeterminada y simplemente aumentar el número de --workers , lo que obtienes es básicamente una cantidad de procesos (administrados por Gunicorn) que se comportan como el servidor de desarrollo app.run() . 4 trabajadores == 4 solicitudes concurrentes. Esto se debe a que Gunicorn usa su tipo de trabajador de sync incluido de manera predeterminada.

Es importante señalar que Gunicorn también incluye trabajadores asincrónicos, es decir, eventlet y gevent (y también tornado , pero que es mejor usar con el marco de Tornado, al parecer). Al especificar uno de estos trabajadores de --worker-class con el --worker-class , lo que obtienes es que Gunicorn administre varios procesos asíncronos, cada uno de los cuales administra su propia concurrencia. Estos procesos no usan hilos, sino corutinas. Básicamente, dentro de cada proceso, aún solo puede suceder 1 cosa a la vez (1 hilo), pero los objetos pueden ''pausarse'' cuando esperan que los procesos externos finalicen (piense en las consultas a la base de datos o en la E / S de red).

Esto significa que, si está utilizando uno de los trabajadores de sincronización de Gunicorn, cada trabajador puede manejar muchas más de una sola solicitud a la vez. El número máximo de trabajadores depende de la naturaleza de su aplicación, su entorno, el hardware en el que se ejecuta, etc. Se pueden encontrar más detalles en la página de diseño de Gunicorn y las notas sobre cómo funciona gevent en su página de introducción.