Se que lo mande antes pero asà seguimos por aquà como dijo F.
A principios de este mes sacamos el NGiNX con los mongrels y el spawncgi
para php por que se hacÃa bastante duro de mantener. Probamos el
mod_rails unos dÃas con la
aplicación de gastos que la que más chicha lleva de la empresa y la
verdad es que cambiamos toda la DMZ y dejamos Apache + mod_rails.
De momento 0 problemas. Alguna vez el Monit manda algún mensajillo de
uso de CPU (por los backups) pero de memoria nada.
Pues nada, que me habéis convencido. Probaré a montarlo en una web que
tengo por ahà sin demasiada carga a ver que pasa.
Gracias por la info.
Saludos
Pablo Formoso E. escribió:
2008/9/23 Borja MartÃn [email protected]:
Pues nada, que me habéis convencido. Probaré a montarlo en una web que tengo
por ahà sin demasiada carga a ver que pasa.
Hay un tema de mod_rails que tendras que tener en cuenta. Los procesos
tienen un tiempo de vida, si durante 5 minutos la aplicación no la
toca nadie, el proceso muere, de manera que la proxima petición deberá
arrancar un proceso nuevo.
Digo 5 minutos pero ahora no recuerdo bien los valores por defecto,
pero eso es totalmente configurable.
El mar, 23-09-2008 a las 14:08 +0200, Francesc E. escribió:
Digo 5 minutos pero ahora no recuerdo bien los valores por defecto,
pero eso es totalmente configurable.
Si por defecto son 300 seg. recomiendan poner como tiempo 2 x (media de
segundos entre visitantes).
PassengerPoolIdleTime [segundos]
Una cosa,
¿y no es más eficiente en cuanto a velocidad tener los procesos siempre
en memoria y por eso aquello de tener las instancias de mongrel siempre
corriendo? porque si tengo una página que no tiene un tráfico continuo,
entiendo que cada vez que entren se va a arrancar la aplicación de
nuevo, ¿no?
o igual tampoco pasa nada por ponerle el tiempo de vida de por ejemplo
24 horas…
Saludos
Pablo Formoso E. escribió:
2008/9/23 Borja MartÃn [email protected]:
¿y no es más eficiente en cuanto a velocidad tener los procesos siempre en
memoria y por eso aquello de tener las instancias de mongrel siempre
corriendo? porque si tengo una página que no tiene un tráfico continuo,
entiendo que cada vez que entren se va a arrancar la aplicación de nuevo,
¿no?
o igual tampoco pasa nada por ponerle el tiempo de vida de por ejemplo 24
horas…
Piensa que un proceso de mod_rails no esta ligado a una pagina, sino a
un vhost/aplicacion. Si el vhost tiene faena para 5 procesos mantiene
los 5, pero si hubo un pico de 5 y luego vas con 2 a ralenti, solo
gasta 2. En ese sentido esta bien.
Por otro lado, si en una misma maquina tienes 7 aplicaciones pequeñas
corriendo no es necesario ya que alocates un numero fijo de mongrels
en cada una, puedes ponerle un maximo a mod_rails y el solo dara mas o
menos procesos a cada aplicacion segun la carga del momento.
Un timeout u otro tiene sus ventajas segun el setup.
2008/9/23 Borja MartÃn [email protected]:
¿y no es más eficiente en cuanto a velocidad tener los procesos siempre en
memoria y por eso aquello de tener las instancias de mongrel siempre
corriendo? porque si tengo una página que no tiene un tráfico continuo,
entiendo que cada vez que entren se va a arrancar la aplicación de nuevo,
Creo que hay la opción de que el proceso se quede en memoria.
Como bien dices, si tu aplicación no tiene tráfico continuo, puede ser
que los workers “mueran” y tengas que arrancarlos de nuevo. Esto va
perfecto para empresas de hosting como dreamhost donde la gente mete
aplicaciones con poco tráfico.
2008/9/23 Xavier N. [email protected]:
Piensa que un proceso de mod_rails no esta ligado a una pagina, sino a
un vhost/aplicacion. Si el vhost tiene faena para 5 procesos mantiene
los 5, pero si hubo un pico de 5 y luego vas con 2 a ralenti, solo
gasta 2. En ese sentido esta bien.
Tienes razón, en ese sentido va bien siempre que tengamos en cuenta de
que la memoria del numero total de procesos máximos no sea superior en
tamaño a la de nuesta maquina.
(Creo que lo he dicho bien, me he leido la frase tres veces antes de
enviar)
Y otro tema interesante de mod_rails es que tiene un modulo de upload
de ficheros para que hace que no se bloqueen los workers.
Xavier, el consumo de memoria despues de varias semanas de uso está
dentro de niveles razonables? O teneis que reiniciar procesos.
2008/9/23 Francesc E. [email protected]:
2008/9/23 Xavier N. [email protected]:
Piensa que un proceso de mod_rails no esta ligado a una pagina, sino a
un vhost/aplicacion. Si el vhost tiene faena para 5 procesos mantiene
los 5, pero si hubo un pico de 5 y luego vas con 2 a ralenti, solo
gasta 2. En ese sentido esta bien.Tienes razón, en ese sentido va bien siempre que tengamos en cuenta de
que la memoria del numero total de procesos máximos no sea superior en
tamaño a la de nuesta maquina.
Correcto :-).
Analogamente el numero de mongrels totales en una maquina tambien
tiene ese tope, solo que son fijos, y son fijos por aplicacion.
2008/9/23 Francesc E. [email protected]:
Y otro tema interesante de mod_rails es que tiene un modulo de upload
de ficheros para que hace que no se bloqueen los workers.Xavier, el consumo de memoria despues de varias semanas de uso está
dentro de niveles razonables? O teneis que reiniciar procesos.
Por ahora todo normal, ademas con REE el consumo de memoria es menor y
lanzar procesos es mas ligero. Usar mod_rails con MRI standard tiene
menos gracia.
Osti … REE
Ruby Enterprise Edition
El día 23 de septiembre de 2008 23:10, Guillermo
[email protected]
escribió:>
2008/9/23 Francesc E. [email protected]
Osti … REE
Que es REE … google no me lo aclara 
Gracias
f.
2008/9/23 Francesc E. [email protected]
Osti … REE
Ruby Enterprise Edition
Lo llevo usando unos meses y va bien, sin pasanger. Cansado de esperar
una
versión oficial de debian para producción que corrigiese fallos, decidÃ
migrar a REE.
A nivel práctico no notas ninguna diferencia. Teóricamente REE tiene ya
aplicados los parches del recolector de basura, para optimizar
mÃnimamente
ruby para rails, y se compromenten a tenerlo activo cuando salgan
fallos.
La ventaja por la que consume menos la combinación Passanger+REE es que
para
el framework, si mal no recuerdo haber leido, usa una especie de memoria
compartida, por lo que todo rails carga solo una vez, y según la
instancia/proceso cambia cosas, esas nuevas cosas se separan de esa
“memoria
compartida”. Al parecer da muy buenos resultados.
Passanger está chulo, pero si te pasas, coño hazlo bien y migra a ree
que es
gratis, aunque admiten donaciones.
¿REE al principio era de pago?
Un Saludo
On Tue, Sep 23, 2008 at 11:36 PM, Fernando G.
[email protected] wrote:
El dÃa 23 de septiembre de 2008 23:10, Guillermo
[email protected] escribió:2008/9/23 Francesc E. [email protected]
Osti … REE
Que es REE … google no me lo aclara
Hey Fernando, es Ruby Enterprise Edition.
Passenger con un Ruby normal tiene como bueno lo de la configuracion
sencilla etc. pero esa es la mitad de la historia, si usas REE con
Passenger entonces tienes el pack completo con algo de mejor
rendimiento en req/s y reducciones de consumo de memoria del orden de
30%:
Performance and memory usage comparisons — Ruby Enterprise Edition
Esto es debido a que Passenger aprovecha lo que se explica aqui:
Frequently Asked Questions — Ruby Enterprise Edition
Por otro lado si corres Mongrel sobre REE tampoco aprovechas el
copy-on-write. Passenger y REE van juntos.
El día 23 de septiembre de 2008 23:45, Xavier N. [email protected]
escribió:>> Que es REE … google no me lo aclara
Hey Fernando, es Ruby Enterprise Edition.
Dios mío… entreprise edition… estamos perdidos :)… en cuanto salga
el R2EE ya todo habrá terminado…
Gracias Xavier
f.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs