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 tiene que iniciar una nueva copia de su aplicación, que puede tomar varios segundos, incluso en una máquina rápida. Para solucionar el problema, hay algunas opciones de configuración de Apache que puede usar para mantener su aplicación activa.
Esto es específicamente lo que he hecho 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 utilizar el modo de desove "inteligente" y apagar PassengerMaxPreloaderIdleTime, Pasajero mantendrá 1 copia de su aplicación en la memoria en todo momento (después de la primera petición después de comenzar Apache). Los oyentes individuales Application
serán fork
ed a partir de esta copia, que es una operación súper barata. Sucede tan rápido que no puede decir si su aplicación ha generado o no un oyente.
Si su aplicación es incompatible con el desove inteligente, le recomendaría mantener un PassengerPoolIdleTime grande y acceder a su sitio periódicamente usando curl y cronjob o monit o algo así para asegurar que el oyente se mantenga con vida.
La Passenger User Guide es una referencia impresionante para estas y otras opciones de configuración.
edición: Si su aplicación no es compatible con el desove inteligente, hay algunas opciones nuevas que son muy agradable
# 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 se combinan PassengerPreStart y PassengerMinInstances, pasajeros girará hasta 3 instancias inmediatamente después de que apache carga, y siempre mantendrá al menos 3 instancias arriba, por lo que sus usuarios raramente (si alguna vez) ven un retraso.
O, si está utilizando desove inteligente (recomendado) con PassengerMaxPreloaderIdleTime 0
ya, puede agregar PassengerPreStart
para obtener el beneficio adicional de la puesta en marcha inmediata.
Muchas gracias a los héroes en phusion.nl!
También encontré esta pepita en el sitio de Passenger Doc: http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerPreStart – dewrich
@dewrich Encontré una herramienta (http://wekkars.com) que hace exactamente lo que hace tu cronjob – SteenhouwerD