Recomendaciones (y diferencias) entre diferentes servidores web de producción de Ruby on Rails

Muy pronto planeo implementar mi primera aplicación Ruby on Rails en un entorno de producción e incluso he elegido un alojamiento web con todo el servidor administrado y la bondad de Capistrano que esperaría de un proveedor de RoR.

El proveedor permite los servidores web Mongrel, Thin, Passenger y FastCGI, lo que parece muy flexible, pero honestamente no conozco las diferencias entre ellos. Los he investigado un poco, pero cuando se empiezan a hablar de características y solicitudes simultáneas máximas, todo se vuelve un poco extraño, y parece que estos datos varían dependiendo de quién los publique.

He mirado al Pasajero (en la superficie), que me parece muy atractivo, pero tenía la impresión de que el Pasajero no era el servidor web real, y en su lugar era más como una capa sobre Apache o nginx y se generó Instancias de la aplicación (como un cluster mestizo).

¿Puede alguien aclararme las diferencias en los términos de los laicos para que pueda elegir sabiamente? (Porque cualquiera que haya visto a Indiana Jones y The Last Crusade sabe lo que sucede si elige mal).

Respuesta corta

Ir con Apache / Nginx + Pasajero. El pasajero es rápido , confiable, fácil de configurar y desplegar. Pasajeros han sido adoptados por un gran número de aplicaciones de Rails grandes, incluyendo Shopify .

texto alt http://sofes.miximages.com/ruby-on-rails/passenger_mongrel_thin_benchmark.png

La respuesta larga

Olvídate de CGI y FastCGI. Al principio no existían otras alternativas, por lo que la única forma de ejecutar Rails era usar CGI o FastCGI, el navegador más rápido. Hoy en día casi nadie corre Rails bajo CGI. Las últimas versiones de Rails ya no ofrecen los corredores .cgi y .fcgi.

Mongrel ha sido una solución ampliamente adoptada, el mejor reemplazo para CGI y FCGI. Muchos sitios aún utilizan el clúster Mongrel y Mongrel, sin embargo, el proyecto de Mongrel está casi muerto y muchos proyectos ya se han trasladado a otras soluciones (en su mayoría, Pasajeros). Además, una architecture basada en Mongrel es bastante difícil de configurar porque necesita un proxy frontend (thin, ngnix) y una architecture backend compuesta por varias instancias de Mongrel.

Pasajero ha estado ganando atención generalizada desde su lanzamiento. Muchos proyectos cambiaron de Mongrel a Passenger por muchas razones, entre las que se incluyen (pero no se limitan a) una implementación, facilidad de mantenimiento y rendimiento fáciles. Además, Passenger ahora está disponible para Apache y Ngnix.

La forma más sencilla de utilizar Passenger es la configuración de Apache + Passenger. Una instalación de Apache y múltiples procesos de Pasajeros.

Si necesita un mejor rendimiento y escalabilidad, puede usar Ngnix como un proxy de frontend y reenviar todas las solicitudes de Rails a múltiples servidores backend, cada uno compuesto por Apache + Passenger. No voy a entrar en los detalles técnicos aquí, esta solución está destinada a ser utilizada por proyectos de Rails con un alto nivel de tráfico.

Las soluciones aún más complejas incluyen una combinación de diferentes niveles que incluyen servidores proxy y servidores http. Puedes tener una idea de lo que estoy hablando acerca de leer algunos detalles internos de GitHub y Heroku .

En este momento, Passenger es la mejor respuesta para la mayoría de los proyectos de Rails.

Mongrel y Thin son servidores de proceso ruby ​​únicos que ejecutaría de forma múltiple como un clúster detrás de algún tipo de proxy (como Apache o Nginx). El proxy administraría qué instancia de Mongrel o Thin atiende las solicitudes.

El pasajero crea una interfaz entre Apache o Nginx que crea un proceso de generación de aplicaciones y luego procesa los procesos para que el servidor reciba las solicitudes entrantes a medida que ingresan. Hay muchas opciones de configuración para la duración de esos procesos, la cantidad de procesos que pueden existir y Cuántas peticiones servirán antes de morir. Esta es, con mucho, la forma más común de escalar y manejar una aplicación de alto tráfico, pero no está exenta de inconvenientes. Esto solo puede hacerse en un sistema operativo * nix (linux, mac os x, etc.). Además, estos procesos se activan a pedido, por lo que, si nadie accede a su sitio durante un tiempo, procesa el proceso y la siguiente solicitud tiene la demora de que se inicie nuevamente. Con Mongrel y Thin, el proceso siempre se está ejecutando. A veces, sin embargo, los procesos nuevos y frescos pueden ser buenos para el uso de la memoria, etc.

Si va a ser un sitio de tráfico relativamente bajo, Mongrel o Thin proporcionan una forma sencilla y fácil de administrar para implementar la aplicación. Para los sitios de mayor tráfico donde necesita la cola inteligente y la gestión de procesos de algo como Passenger, es una muy buena solución.

En cuanto a fastcgi, probablemente quieras usar eso como una última opción.

Yo uso Passenger + nginx. Funciona realmente, muy bien.

Para obtener un alarde de rendimiento instantáneo con el pasajero, recomiendo usar Ruby Enterprise Edition.

    Intereting Posts