A ver.... Supongamos que programas tu aplicacion Rails y la pones a escuchar en el puerto, digamos, 3000. Tu aplicacion puede hablar con un solo web browser a la vez. Esto esta bien hasta que empezas a tener muchos web browsers tratando de hablar con tu aplicacion al mismo tiempo. Resultado: como solo hay una sola aplicacion y esta solo puede manejar un cliente a la vez, cada cliente tiene que esperar a que el cliente anterior termine de hablar con tu aplicacion, un tiempo potencialmente alto.
Para poder hablar con muchos clientes al mismo tiempo, lo que se hace actualmente es lanzar varias instancias de tu _misma_ aplicacion, cada una escuchando en un puerto diferente. Si usas mongrel como web server de tu aplicacion rails (tambien podrias estar usando webrick, lo cual no es muy recomendable ya que mongrel es mas rapido y moderno), entonces lanzaras un "cluster" de mongrels: una app con mongrel escuchando en el puerto 3000, otra escuchando en el puerto 3001, otra en el puerto 3002, etc.... Ahora podes hablar con tantos clientes al mismo tiempo como aplicaciones escuchando en diferentes puertos tengas. Solo queda algo por resolver: ¿quien le dice al primer browser que hable con el puerto 3000, al segundo que hable con el 3001, etc...? Tenes que poner algo en el medio que decida. Ese algo puede ser un Proxy, un web server, etc. Ejemplos: Pound, Apache o, lo que preguntaste, NGINX, que es un web server. La ventaja de poner un web server como NGINX es que el tipo despacha contenido estatico (todo aquello que no cambia o no depende de una logica de aplicacion -- ejemplo: imagenes, archivos css, etc..) a las chapas. Por lo tanto, si se da cuenta de que el browser esta pidiendo un archivo estatico, despacha el archivo el mismo. Al contrario, si por la ruta que solicita el cliente se da cuenta de que necesita hacerlo hablar con una aplicacion rails, el tipo redirige al cliente al primer mongrel que encuentre libre. Bueno eso es todo, el tema es que a veces la configuracion puede ser algo compleja. Por eso se dice que en rails es mas facil el desarrollo de la aplicacion que el _deployment_ es decir, la configuracion de los servidores una vez que la plicacion ya entra en la etapa de produccion. Emmanuel José Ribes <[EMAIL PROTECTED]> escribió: Buenas, soy Jose y también un novato en RoR. Pensaba que con Mongrel como servidor estaba todo resuelto pero veo que no es así. Me van a disculpar la pregunta, pero cual es la relación entre Nginx y los Cluster de Mongrels, es decir el porque de montar ambos, que trabajo desempeñan cada uno de ellos, cómo se relacionan entre sí, etc. Gracias por adelantado. El día 14/06/07, Adrian Madrid <[EMAIL PROTECTED]> escribió: Felicitaciones! El sitio se ve muy bien organizado y claro para usar. Seria genial si pudieran discutir mas a fondo acerca de las decisiones que tomaron y lo que aprendieron al trabajar en este projecto. Todos estamos aprendiendo y a veces trabajando en proyectos de ese tamanio es interesante los desafios que se presentan. Sinceramente, Adrian Madrid On 6/13/07, Michel Martens <[EMAIL PROTECTED]> wrote: > Con un equipo de programadores 100% rioplatense, acabamos de lanzar el > nuevo website de DESIGN 21: Social Design Network, un proyecto > conjunto de la agencia japonesa Felissimo y la UNESCO cuyo objetivo es > reunir a diseñadores de todo el mundo con organizaciones y empresas > dispuestas a lograr un cambio a través del diseño. > > El equipo estuvo conformado por Manuel Aristarán (viajó a París para > coordinar las operaciones desde las oficinas de Area 17[1], la empresa > para la que realizamos este trabajo), Luis Lavena desde Tucumán, Diego > Algorta desde Montevideo y quien les escribe desde Buenos Aires. > > Desde el minuto cero pusimos especial atención en escribir código > mantenible y testeado, y para lograrlo utilizamos RSpec toda vez que > pudimos. Como consecuencia, llegamos al final del proyecto con más de > 360 ejemplos sobre modelos, controladores e integraciones de vistas. > > Algunos detalles técnicos: > > * Ruby on Rails, Nginx, MySQL, Cluster de Mongrels. > * Un servidor de desarrollo en Francia; Dos servidores de producción y > uno de stagging en EngineYard. > * Backend desarrollado sobre Roar[2] > * Tan RESTful como fue posible. > * 27 controllers, 50 models, 368 specs. > > Sin nada más que agregar: http://design21sdn.com > > Saludos. > > Michel. > > > 1. http://area17.com > 2. http://nanoware.com/roar/ > _______________________________________________ > ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > -- Adrian Esteban Madrid _______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar _______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar --------------------------------- Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya!
_______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
