Me voy a centrar en el comportamiento lento del cliente y en cómo su configuración lo maneja, pero no caiga en la tentación de creer que ese es el único beneficio. El mismo método que beneficia a los clientes lentos también tiene beneficios para los clientes rápidos, el manejo de SSL, el manejo de sobretensiones y otros aspectos de servir HTTP en Internet.
Gunicorn es un software de bifurcación previa. Para las comunicaciones de baja latencia, como el equilibrador de carga al servidor de aplicaciones o las comunicaciones entre servicios, los sistemas pre-fork pueden ser muy exitosos. No hay ningún costo en acelerar un proceso para manejar la solicitud, y un solo proceso puede dedicarse a manejar una sola solicitud; La eliminación de estas cosas puede conducir a un sistema general más rápido y eficiente hasta que la cantidad de conexiones simultáneas exceda la cantidad de procesos disponibles para manejarlas.
En su situación, está tratando con clientes de alta latencia a través de Internet. Estos clientes lentos pueden vincular esos mismos procesos. Cuando QPS es importante, el código de la aplicación debe recibir, manejar y resolver la solicitud lo más rápido posible para que pueda pasar a otra solicitud. Cuando los clientes lentos se comunican directamente con su sistema, vinculan ese proceso y lo ralentizan. En lugar de manejar y eliminar la solicitud lo más rápido posible, ese proceso ahora también tiene que esperar al cliente lento. El QPS efectivo disminuye.
El manejo de grandes cantidades de conexiones con muy poco costo de CPU y memoria es en lo que son buenos los servidores asíncronos como Nginx. Los clientes lentos no los afectan de la misma manera negativa porque son expertos en manejar grandes cantidades de clientes simultáneamente. En el caso de Nginx, ejecutándose en hardware moderno puede manejar decenas de miles de conexiones a la vez.
Nginx frente a un servidor de pre-bifurcación es una gran combinación. Nginx maneja las comunicaciones con los clientes, y no sufre una penalización por manejar clientes lentos. Envía solicitudes al backend tan rápido como el backend puede manejar esas solicitudes, permitiendo que el backend sea lo más eficiente posible con los recursos del servidor. El backend devuelve el resultado tan pronto como lo calcula, y Nginx amortigua esa respuesta para alimentarlo y ralentizar a los clientes a su propio ritmo. Mientras tanto, el backend puede pasar a manejar otra solicitud incluso cuando el cliente lento aún está recibiendo el resultado.
@blueben tiene razón. Un ejemplo específico y común de lo que puede suceder cuando no se usa un proxy inverso es que una base de datos de back-end puede quedarse sin identificadores de conexión de la base de datos donde no hay proxy y hay un pico de tráfico. Esto se debe a que las conexiones tardan en liberarse como se describe en @blueben.
Un primer instinto para ver que las bases de datos se están agotando podría ser admitir más conexiones de base de datos. Pero al agregar un proxy inverso frente a la aplicación, verá que la cantidad de conexiones de base de datos requeridas para una carga alta disminuye significativamente y se estabiliza: el nivel de conexión de la base de datos no aumentará tanto cuando haya un aumento en el tráfico.
Nginx también es excelente para servir contenido estático, almacenamiento en caché y una variedad de otras tareas HTTP, permitiendo que su servidor de aplicaciones se enfoque en ser un servidor de aplicaciones.
fuente
@naill Donegan menciona esto en el comentario anterior, pero es lo suficientemente importante como para garantizar una respuesta.
Nginx detiene el lento ataque de loris que gunicorn no maneja.
fuente