Inicio lento del servidor inicial cuando se usa Phusion Passenger y Rails


87

Para subirse al carro de la banda de Phusion Passenger, hemos configurado un servidor de prueba para una pequeña aplicación de rieles para probar las cosas.

Hasta ahora ha sido muy agradable de usar, hace que instalar / configurar e implementar aplicaciones sea muy sencillo. El problema es que el sitio que usamos no se ve afectado con mucha frecuencia y parece cerrar los servidores en segundo plano. Lo que significa que cuando alguien va al sitio tiene una espera muy larga hasta que inicia un nuevo servidor para manejar la solicitud. Leímos la documentación, probamos bastantes configuraciones diferentes (modos smart / smart-lv2, pasajero, etc.) y todavía no hemos encontrado una solución real.

Después de analizar los resultados de Google, realmente no podemos encontrar información útil. Actualmente tenemos un trabajo cron que realiza una solicitud de vez en cuando en un intento de mantener los servidores en funcionamiento.

¿Alguien más está experimentando este problema y tiene algún consejo para solucionarlo?


También encontré esta pepita en el Passenger Doc Site: modrails.com/documentation/…
dewrich

@dewrich Encontré una herramienta ( wekkars.com ) que hace exactamente lo que está haciendo tu cronjob
SteenhouwerD

Respuestas:


119

Lo que está sucediendo es que su aplicación y / o ApplicationSpawners se están cerrando debido al tiempo de espera. Para procesar su nueva solicitud, Passenger debe iniciar una nueva copia de su solicitud, lo que puede demorar varios segundos, incluso en una máquina rápida. Para solucionar el problema, existen algunas opciones de configuración de Apache que puede utilizar para mantener viva su aplicación.

Esto es específicamente lo que hice en mis servidores. PassengerSpawnMethod y PassengerMaxPreloaderIdleTime son las opciones de configuración más importantes en su situación.

# Speeds up spawn time tremendously -- if your app is compatible. 
# RMagick seems to be incompatible with smart spawning
# Older versions of Passenger called this RailsSpawnMethod
PassengerSpawnMethod smart

# Keep the application instances alive longer. Default is 300 (seconds)
PassengerPoolIdleTime 1000

# Keep the spawners alive, which speeds up spawning a new Application
# listener after a period of inactivity at the expense of memory.
# Older versions of Passenger called this RailsAppSpawnerIdleTime
PassengerMaxPreloaderIdleTime 0

# Just in case you're leaking memory, restart a listener 
# after processing 5000 requests
PassengerMaxRequests 5000

Al usar el modo de generación "inteligente" y desactivar PassengerMaxPreloaderIdleTime, Passenger mantendrá 1 copia de su aplicación en la memoria en todo momento (después de la primera solicitud después de iniciar Apache). Los Applicationoyentes individuales serán forkeditados a partir de esta copia, que es una operación súper barata. Sucede tan rápido que no puede saber si su aplicación ha tenido que generar un oyente.

Si su aplicación es incompatible con la generación inteligente, le recomiendo mantener un PassengerPoolIdleTime grande y visitar su sitio periódicamente usando curl y un cronjob o monit o algo para asegurarse de que el oyente permanezca vivo.

La Guía del usuario del pasajero es una excelente referencia para estas y más opciones de configuración.

editar : si su aplicación es incompatible con el spawning inteligente, hay algunas opciones nuevas que son muy buenas

# Automatically hit your site when apache starts, so that you don't have to wait
# for the first request for passenger to "spin up" your application. This even
# helps when you have smart spawning enabled. 
PassengerPreStart http://myexample.com/
PassengerPreStart http://myexample2.com:3500/

# the minimum number of application instances that must be kept around whenever 
# the application is first accessed or after passenger cleans up idle instances
# With this option, 3 application instances will ALWAYS be available after the
# first request, even after passenger cleans up idle ones
PassengerMinInstances 3

Por lo tanto, si combina PassengerPreStart y PassengerMinInstances, Passenger activará 3 instancias inmediatamente después de que se cargue Apache y siempre mantendrá al menos 3 instancias, por lo que sus usuarios rara vez (si es que alguna vez) verán un retraso.

O, si ya está utilizando el spawning inteligente (recomendado) PassengerMaxPreloaderIdleTime 0, puede agregarlo PassengerPreStartpara obtener el beneficio adicional del inicio inmediato.

¡Muchas gracias a los héroes de phusion.nl !


Muchas gracias por su respuesta. Creo que hemos probado la mayoría de esos ajustes, pero tal vez no en la combinación correcta. Me pondré a prueba mañana y revertiré.
tsdbrown

Esto es asombroso. Estaba teniendo el mismo problema con la instalación de mi Nginx / Phusion Passenger y esto me ayudó muchísimo.
Scott Anderson

Probé esta configuración y no veo mejoras de rendimiento, pero nuestra aplicación usa RMagick. ¿Existen soluciones alternativas para esto? ¿Por qué no funciona con RMagick?
Chip Castle

1
RailsSpawnMethodestá en desuso a favor de PassengerSpawnMethod modrails.com/documentation/…
paulus

1
Hola, tengo el mismo problema y me gustaría probar esa configuración, pero no sé dónde debe colocarse esa configuración. ¡Gracias!
joseramonc

41

En caso de que haya algún usuario del servidor nginx que se encuentre con esta pregunta, las directivas 'PassengerMaxRequests' y 'PassengerStatThrottleRate' no se traducen a nginx. Sin embargo, los demás lo hacen:

rails_spawn_method smart;
rails_app_spawner_idle_time 0;
rails_framework_spawner_idle_time 0;
passenger_pool_idle_time 1000;

HTH!

EDITAR rails_spawn_methodestá obsoleto en el pasajero 3 en lugar de usar

passenger_spawn_method smart; 

todo lo demás está bien hasta la fecha.


7
Gracias por esto. Una cosa a tener en cuenta es que tuve que rellenar pasajero_pool_idle_time en mi nginx.conf principal con las otras configuraciones globales en lugar de solo en la configuración del sitio específico donde se habilitaron los rieles.
Scott Anderson

pero error en el pasajero 4:"passenger_max_preloader_idle_time" directive is duplicate
TangMonk


2

RE:

# Additionally keep a copy of the Rails framework in memory. If you're 
# using multiple apps on the same version of Rails, this will speed up
# the creation of new RailsAppSpawners. This isn't necessary if you're
# only running one or 2 applications, or if your applications use
# different versions of Rails.
RailsFrameworkSpawnerIdleTime 0

Solo algo para agregar y podría ser útil.

El método de generación predeterminado en la versión actual es "smart-lv2", que omite el generador de marco, por lo que configurar el tiempo de espera del generador de marco no tendría efecto de todos modos a menos que establezca explícitamente el método de generación en "inteligente".

Fuente: http://groups.google.com/group/phusion-passenger/browse_thread/thread/c21b8d17cdb073fd?pli=1


1

Si su host es un servidor compartido, como el mío, no puede cambiar la configuración y está bloqueado con un trabajo cron.


Afortunadamente, para esta aplicación en particular no lo es. Pero lo tendré en cuenta para el futuro, gracias.
tsdbrown

1

También tuve este problema, pero no pude cambiar la configuración del pasajero porque no tenía permiso de escritura para este archivo. Encontré una herramienta ( http://www.wekkars.com ) que hace que mi aplicación responda rápidamente. Quizás esto también pueda ser una solución para ti.


0

comprobar la versión del pasajero. fue RailsSpawnMethod <string>para versiones antiguas.

Si es así (si no recuerdo mal), reemplace Passenger con Rails en todas las directivas de configuración o busque documentos antiguos de pasajeros para obtener más detalles.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.