2009/10/7 Porta <[email protected]>: > Consulta relacionada: > todo esto que están diciendo, aplica a Merb? o solo a RoR? (tengo un par de > apps que hice con Merb y las tengo que pasar a producción). Arranqué con > Ruby/Merb la semana pasada (de ahi la ignorancia) y no tengo mucha idea de > que se usa en producción generalmente. > Tengo corriendo apache2 en linux, en caso de que alguien pregunte.
Dígale No Al Top Posting. Aplica a cualquier aplicación que use Rack de fondo (rails, merb, sinatra, ramaze, camping…) ya que todos los servers estos son compatibles con rack. > 2009/10/7 Nicolás Sanguinetti <[email protected]> >> >> 2009/10/7 Luis Lavena <[email protected]>: >> > 2009/10/7 Nicolás Sanguinetti <[email protected]>: >> >> On Wed, Oct 7, 2009 at 6:19 PM, Luis Lavena <[email protected]> >> >> wrote: >> >>> 2009/10/7 Nicolás Sanguinetti <[email protected]>: >> >>>> [...] >> >>>> >> >>>> -foca >> >>>> >> >>>> [1] Bueno, thin no corre en windows, pero a quién le importa? (Hola >> >>>> Luis :P) >> >>> >> >>> Thin corre en Windows: >> >>> >> >>> http://blog.mmediasys.com/2009/10/06/lot-of-small-but-rewarding-news/ >> >>> >> >>> http://wiki.github.com/luislavena/rake-compiler/projects-using-rake-compiler >> >> >> >> Cool :D >> >> >> >> Igual, usaría unicorn o passenger en producción. Hay poca cosa más >> >> aburrida/frustrante que lidiar con monit/god/etc. >> >> >> > >> > Tenes razon, pero ahora te hago este planteo, de un caso real. >> > >> > Dada una aplicacion donde no tenes sleep o timeout por inactividad >> > (que todo el tiempo tiene trafico) Los spawned processes de Passenger >> > generalmente van a crecer, y crecer y crecer... >> > >> > Passenger no es muy inteligente en lo que refiere a administracion de >> > memoria. >> > >> > En esos casos, ni MaxPoolSize, ni Timeout pueden ayudarte mas que >> > salir a averiguar por que tu aplicacion leakea y rascarte la cabeza >> > para poner una solucion que no sea tmp/restart.txt >> > >> > Ya que, AFAIK, restart.txt mata todos los spawned processes, >> > generandote un vacio de varios segundos hasta que un nuevo server >> > puede responder tus requests. >> >> En ese caso, no uses passenger, y no uses unicorn (que tiene el mismo >> problema). Cómo decía, la mejor solución depende de cada problema >> específico. >> >> Rainbows! http://rainbows.rubyforge.org/ >> >> (no lo probé ni nada, pero ta, es unicorn pensado para long/sleepy >> requests, digo, ya que decís… :P) >> >> -foca >> >> > -- >> > Luis Lavena >> > AREA 17 >> > - >> > Perfection in design is achieved not when there is nothing more to add, >> > but rather when there is nothing more to take away. >> > Antoine de Saint-Exupéry >> > _______________________________________________ >> > 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 > > > _______________________________________________ > 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
