¿Por qué necesito nginx cuando tengo uWSGI?

Hay muchos tutoriales sobre cómo configurar nginx para cooperar con uWGSI cuando quiero implementar la aplicación Django.

Pero, ¿por qué necesito nginx en este kit? uWSGI en sí mismo puede servir aplicaciones WSGI Python, puede servir archivos estáticos, también puede hacer SSL. ¿Qué puede hacer nginx que uWSGI no puede hacer?

Usted no

De todos modos, esa es la respuesta simple: no la necesita . uWSGI es en sí mismo un servidor capaz.

Sin embargo, otros servidores como nginx han existido por más tiempo y son (probablemente, de todos modos) más seguros, además de tener características adicionales que no son compatibles con uWSGI, por ejemplo, un mejor manejo de los recursos estáticos (a través de cualquier combinación de Expires o E-Tag encabezados, compresión gzip, gzip precomprimido, etc.) que pueden reducir significativamente la carga del servidor y la red; Además, un servidor como nginx frente a su aplicación Django también puede implementar el almacenamiento en caché de su contenido dinámico, lo que ayuda a reducir la carga del servidor e incluso ayuda a facilitar el uso de un CDN (que normalmente no funciona bien con el contenido dinámico) ) Incluso podría ir más allá y tener nginx en un servidor completamente separado, revertir las solicitudes de proxy para contenido dinámico a un clúster de carga equilibrado de servidores de aplicaciones mientras maneja el contenido estático en sí.

Por ejemplo, mi blog (aunque es WordPress, tiene nginx delante) está sintonizado para almacenar en caché las publicaciones durante 24 horas, y para almacenar en caché las páginas de índice durante 5 minutos; Si bien no veo suficiente tráfico para que eso realmente importe la mayor parte del tiempo, ayuda a mi pequeño VPS a resistir el aumento ocasional que de otro modo podría detenerlo, como el gran aumento del tráfico cuando uno de mis artículos fue elegido por un Twitterer con muchos miles de seguidores, muchos de los cuales lo tuitearon a sus miles de seguidores.

Si hubiera estado ejecutando un servidor uWSGI "desnudo" (y suponiendo que hubiera sido un sitio de Django, en lugar de WordPress), podría haber resistido bien, o podría haber fallado y quemado, lo que me costó visitas perdidas . Tener nginx frente a él para manejar esa carga realmente puede ayudar.

Dicho todo esto, si solo está ejecutando un pequeño sitio que no verá mucho tráfico, no hay necesidad real de nginx ni nada más; solo use uWSGI solo si eso es lo que quiere hacer. Por otro lado, si verá mucho tráfico ... bueno, es posible que aún desee uWSGI, pero al menos debería considerar algo en frente para ayudarlo con la carga. En realidad, realmente debería probar diferentes configuraciones de carga con su sitio terminado para determinar qué funciona mejor para usted bajo su carga esperada y usar lo que sea que termine siendo.

En mi opinión, si coloca su sitio web en Internet en lugar de Lab, puede ver la diferencia.

Imagine a un usuario de otro país con un navegador web abierto de baja velocidad de red para acceder a su sitio web. uWSGI manejará esa conexión Http en un hilo. Ese hilo puede pasar bastante tiempo esperando una solicitud Http completa debido a la baja velocidad de la red. Si el tamaño de su grupo de subprocesos es 100, imagine que a 100 usuarios les gusta eso lentamente, ¿qué sucederá? No hay subproceso inactivo para manejar otra solicitud Http.

Pero las cosas son bastante diferentes para Nginx. Nginx está diseñado en 'Patrón Reactor'. Puede buscar en Google 'Reactor Pattern' para ver cómo funciona. En resumen, la conexión de baja velocidad no lo afecta para manejar otras solicitudes Http.