Trabajadores asincrónicos y enhebrados de Gunicorn para Django.
Asincronía
Para operaciones de entrada/salida (IO, por sus siglas en inglés) necesitamos usar código asíncrono y Django no es asíncrono por defecto, pero podemos lograr esto ejecutando gunicorn con el worker gevent y monkey patching:
gunicorn --worker-class=gevent --worker-connections=1000 --workers=3 main:app
Historial de cambios de Gunicorn a partir de 2014 https://docs.gunicorn.org/en/stable/2014-news.html?highlight=monkey#gevent-worker:
corrección: monkey patching ahora se realiza en el worker
1. ¿Aún necesito aplicar el monkey patch a mi aplicación o se hace automáticamente desde un worker?
2. ¿Cómo logra gevent la funcionalidad asíncrona para mi código de Django?
Hilos
Si tenemos una carga de trabajo relacionada con la CPU, necesitamos usar un worker gthread con hilos:
gunicorn --workers=5 --threads=2 --worker-class=gthread main:app
3. Si utilizamos esta configuración para operaciones de entrada/salida, ¿funcionará? Cuando un hilo esté esperando debido a una operación de entrada/salida, ¿podrá el otro hilo seguir trabajando?
4. Entiendo el punto en (3) (si estoy en lo correcto) debido al tiempo de espera en operaciones de entrada/salida, pero si se trata de una carga de trabajo relacionada con la CPU, ¿cómo nos ayudará el segundo hilo en nuestro caso? ¿O solo ayudará si el núcleo no está cargado completamente y hay espacio para que se ejecute otro hilo?
5. ¿Son inútiles (3) y (4) debido al GIL?
Por ejemplo, si 4 personas envían solicitudes al servidor con 1 worker y 4 hilos, el GIL se asegura de que solo 1 hilo trabaje. ¿El primer hilo comienza a procesar con el hilo 1 y los otros 3 están esperando? ¿Entonces cuál es el propósito de los hilos?
davy.ai
Async
Para operaciones relacionadas con la entrada/salida (E/S), necesitamos usar código asíncrono. Django no es asíncrono por defecto, pero podemos lograrlo ejecutando gunicorn con el trabajador gevent y haciendo monkey patching:
gunicorn --worker-class=gevent --worker-connections=1000 --workers=3 main:appSegún el registro de cambios de Gunicorn de 2014, el monkey patching ahora se realiza en el trabajador, por lo que ya no es necesario hacer monkey patching de la aplicación.
Gevent logra la funcionalidad asíncrona para el código de Django mediante el uso de una biblioteca de red de Python basada en coroutines que utiliza greenlet para proporcionar una API síncrona de alto nivel sobre el bucle de eventos de libev.
Threads
Si tenemos una carga relacionada con la CPU, necesitamos usar un trabajador gthread con hilos:
gunicorn --workers=5 --threads=2 --worker-class=gthread main:appSi utilizamos esta configuración para una carga relacionada con la entrada/salida, funcionará. Cuando un hilo está esperando debido a la entrada/salida, el otro hilo podrá trabajar.
Sin embargo, el uso de múltiples hilos no es útil para operaciones relacionadas con la CPU debido al GIL (Bloqueo Global del Intérprete). El GIL se asegura de que solo un hilo pueda ejecutar código Python a la vez. Entonces, si hay cuatro personas enviando solicitudes a un servidor con un trabajador y cuatro hilos, el GIL se asegurará de que solo un hilo trabaje a la vez. Los otros tres hilos esperarán y no ayudarán si el núcleo está completamente cargado por un hilo.
En conclusión, el uso de múltiples hilos no es útil para operaciones relacionadas con la CPU debido al GIL, pero puede mejorar el rendimiento para operaciones relacionadas con la entrada/salida al permitir que se ejecuten más tareas en paralelo.