2009/10/7 Luis Lavena <[email protected]> > 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... >
Tengo entendido que ningún proceso levantado por Passenger vive más de cierto tiempo (configurable), haya o no requests pendientes (el respawn de los procesos lo hace escalonado, no todos juntos para que no se note). Si un proceso ha vivido más allá de ese límite, se lo schedula para restartear (una vez que termine el request actual). Mi (poca) experiencia parece confirmar ese comportamiento. Ahora, puede darse que los long requests metan tanto ruido en ese "escalonado" que termine ocupando todos los procesos para atender requests y/o de repente se restarteen 20 procesos juntos (no dejando ninguno vivo por un lapso determinado)... por algo hay que evitar ese tipo de requests. Por suerte hoy es relativamente más simple implementar un Workling o schedular trabajos en background (aunque, tá, hay demasiadas opciones). Me puse a buscar en la doc y no encuentro nada al respecto, pero sí veo una alternativa: yet another opción, PassengerMaxRequests<http://www.modrails.com/documentation/Users%20guide.html#PassengerMaxRequests>. Que es lo mismo que dije recién pero en lugar de medirse en tiempo, se mide en cantidad de requests (y otra diferencia es que por default está desactivada). Expectante de ser aleccionado, -- nachokb
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
