ruby on rails - run - Delgado vs Unicornio en Heroku

ruby on rails puma server (3)

Solo quería obtener las opiniones de las personas sobre el uso de Unicorn vs Thin como un servidor de rieles. La mayoría de los artículos / puntos de referencia que encontré en línea parecen muy incompletos, por lo que sería bueno tener un lugar centralizado para discutirlo.

Unicron es un servidor de procesos múltiples, mientras que thin es un servidor basado en eventos / no bloqueo. Los servidores basados en eventos son geniales ... si su código es asíncrono / no bloquea, vail rails está bloqueando. Entonces, a menos que uses bibliotecas de rieles que no bloquean, realmente no veo la ventaja de usar Thin. Lo que es peor, en un servidor sin bloqueo, si su bucle de E / S está bloqueando, bloqueará todo el bucle y no podrá gestionar más solicitudes hasta que regrese la llamada de bloqueo. ¡Las bibliotecas de bloqueo disminuirán su velocidad!

¿Por qué Heroku eligió Thin como su servidor predeterminado (para cedro)? Son tipos inteligentes, así que estoy seguro de que tenían una razón.

Bellow es un enlace que sugiere reemplazar a Thin con 4 trabajadores Unicornio, esto tiene mucho sentido para mí. 4 trabajadores de Unicron en Heroku

Heroku no utiliza el enrutamiento inteligente: asignará trabajos aleatoriamente a los dinamómetros independientemente de si el banco de pruebas está ocupado. Por lo tanto, si su dinamómetro no puede manejar múltiples trabajos a la vez, obtendrá latencia (quizás una latencia masiva) incluso si paga por muchos otros dineros que son gratuitos. "Así es, si su aplicación necesita 80 dynos con un enrutador inteligente, necesita 4.000 con un enrutador aleatorio". http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku dice que están trabajando en esto y que su plan es facilitar el uso del Unicornio. Básicamente dijeron "Oops, no notamos que esto fue un problema por unos años ... y ahora que lo vemos, definitivamente es un problema para Thin ... así que supongo que necesitas usar un programa diferente al uno que hemos estado presionando todo este tiempo ". http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

De la explicación oficial de Heroku (segundo enlace arriba): "Rails, de hecho, todavía no admite confiablemente el manejo concurrente de solicitudes. Esto deja a los desarrolladores de Rails incapaces de aprovechar las capacidades de concurrencia adicionales ofrecidas por la pila Cedar, a menos que se muevan a una red concurrente servidor como Puma o Unicornio.

Las aplicaciones Rails implementadas en Cedar con Thin pueden terminar rápidamente con problemas de cola de solicitudes. Debido a que el enrutador Cedar ya no hace cola en nombre de la aplicación, las solicitudes puestas en cola en el banco de pruebas deben esperar hasta que el único proceso de Rails avance por la cola. Muchos clientes se han topado con este problema y no hemos podido tomar medidas y proporcionarles un mejor enfoque para implementar aplicaciones de Rails en Cedar ".

También resulta interesante que sus herramientas de rendimiento, incluida New Relic, no hayan informado sobre el tiempo pasado en la cola de pruebas. http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

Oops.

Recientemente (hace solo unos meses), la gente detrás de Phusion Passenger agrega soporte a Heroku. Definitivamente esta es una alternativa que debes probar y ver si se adapta a tus necesidades.

Es increíblemente rápido incluso con 1 dyno y la caída en el tiempo de respuesta es palpable. Un simple Passenger Ruby Heroku Demo está alojado en github.

Los principales beneficios que reclaman los Pasajeros en Heroku son:

Aceleración de activos estáticos a través de Nginx : no permita que su aplicación Ruby sirva recursos estáticos, deje que Nginx lo haga por usted y descargue su aplicación para las tareas realmente importantes. Nginx hará un trabajo mucho mejor.
Múltiples procesos de trabajo : en lugar de ejecutar solo un trabajador en un banco de pruebas, Phusion Passenger ejecuta múltiples trabajadores en un único banco de pruebas, utilizando así sus recursos al máximo y brindándole más beneficios. Este enfoque es similar al de Unicornio. Pero a diferencia de Unicorn, Phusion Passenger escala dinámicamente la cantidad de procesos de trabajo basados en el tráfico actual, liberando recursos cuando no son necesarios.
Optimizaciones de memoria : Phusion Passenger usa menos memoria que Thin y Unicorn. También es compatible con la copia de escritura de la memoria virtual en combinación con la precarga del código, lo que hace que su aplicación use aún menos memoria cuando se ejecuta en Ruby 2.0.
Búfer de solicitud / respuesta : el Nginx incluido almacena las solicitudes y las respuestas, protegiendo así su aplicación contra clientes lentos (por ejemplo, dispositivos móviles en redes móviles) y mejorando el rendimiento.
Recolección de basura fuera de banda : el recolector de basura de Ruby es lento, pero ¿para qué molestar a los visitantes con tiempos de respuesta largos? ¡Solucione esto ejecutando la recolección de basura fuera del ciclo normal de solicitud-respuesta! Este concepto, introducido por primera vez por Unicorn, se ha mejorado: Phusion Passenger garantiza que solo una solicitud al mismo tiempo ejecute la recolección de basura fuera de banda, eliminando así todos los problemas que tiene la recolección de basura fuera de banda de Unicorn.
Soporte de JRuby : Unicorn es una mejor opción que Thin, pero no es compatible con JRuby. Phusion Passenger lo hace.

Espero que esto ayude.

Thin es fácil de configurar, no es óptimo, pero solo funciona en el entorno Heroku.

Unicorn puede ser más eficiente, pero necesita ser configurado: ¿Cuántos trabajadores? Aplicación de precarga? ¿Qué escoges?

He lanzado aplicaciones de Unicorn Heroku con trabajadores configurados en 3, 5 y 8, solo en función del tamaño de cada aplicación, la cantidad de código, la cantidad de memoria utilizada y la cantidad de tráfico que se obtiene al elegir este número, y usted necesita para monitorear con el tiempo para asegurarse de que obtuvo el número correcto, y su aplicación no se está quedando sin memoria.

Precarga falsa: esto hará que la aplicación se inicie más lentamente, pero cuando Unicorn reinicia a un trabajador, esto es ''más seguro'' con las conexiones de red (memcache, postgres, mongo, etc.)

Precarga verdadera: esto es mejor, pero debe manejar las reconexiones del servidor correctamente en el código de bifurcación anterior y posterior.

Thin no tiene ninguno de estos problemas de forma inmediata, pero solo obtiene el proceso de ejecución.

Resumen: es realmente difícil configurar Unicorn desde el primer momento para que funcione bien (o nada) para todos, mientras que Thin solo puede funcionar para que la gente se ejecute con menos solicitudes de soporte.