¿Es necesario poner Unicorn detrás de Nginx (o Apache)

Question

? Estoy un poco confundido acerca de esta arquitectura. En uno de los proyectos en los que estoy trabajando, Unicorn fue elegido como servidor de Rails. Y está detrás del servidor web Nginx. Como yo entiendo, Unicorn es un servidor web totalmente funcional y no planeamos alojar ninguna otra aplicación de Rails en la misma instancia de servidor.

Así que mi pregunta sería: ¿cuáles son los beneficios de tener capa adicional en la cadena:

client -> nginx -> unicorn -> unicorn worker 

Answer 1

unicornio no fue diseñado para manejar clientes "lentos". Puede leer más sobre esto en el archivo de ayuda PHILOSOPHY:

La mayoría de los puntos de referencia que hemos visto no te dice esto, y un unicornio no se preocupa por los clientes lentos ... pero debería.

Un "cliente lento" puede ser cualquier cliente fuera de su centro de datos. El tráfico de red dentro de una red local siempre es más rápido que el tráfico que cruza fuera de él. Las leyes de la física no permiten lo contrario.

Las conexiones persistentes se introdujeron en HTTP/1.1 reducen la latencia desde el establecimiento de la conexión y el inicio lento TCP. También desperdician recursos del servidor cuando los clientes están inactivos.

Las conexiones persistentes significan que uno de los procesos de trabajo de unicornio (dependiendo de su aplicación, puede ser muy hambriento de memoria) pasaría una gran cantidad de su tiempo inactivo manteniendo viva la conexión y sin hacer nada más. Al ser de un solo subproceso y usar E/S de bloqueo, un trabajador no puede atender a otros clientes mientras mantiene una conexión activa. Por lo tanto, unicornio no implementa conexiones persistentes.

Si las respuestas de su aplicación son más grandes que el búfer de sockets o si está manejando grandes solicitudes (cargas), los procesos de trabajo también serán embotellados por la velocidad de la conexión del cliente. No debe permitir que unicornio atienda clientes fuera de su red local.