Avvio iniziale lento del server quando si utilizzano Phusion Passenger e Rails

Per saltare sul carro della banda di Phusion Passenger abbiamo configurato un server di staging per una piccola app di rotaie per testare le cose.

Finora è stato molto piacevole da usare, rende l'installazione / configurazione e la distribuzione di app un gioco da ragazzi. Il problema è che il sito che stiamo utilizzando non viene colpito molto spesso e sembra che chiuda i server in background. Significa che quando qualcuno va sul sito ha un'attesa davvero lunga prima di avviare un nuovo server per gestire la richiesta. Abbiamo letto la documentazione, provato diverse configurazioni (modalità smart / smart-lv2, passengeridletime ecc.) E ancora non abbiamo trovato una vera soluzione.

Dopo aver analizzato i risultati di Google, non possiamo davvero trovare informazioni utili. Attualmente abbiamo un cron job che fa una richiesta ogni tanto nel tentativo di mantenere i server in esecuzione.

Qualcun altro sta riscontrando questo problema e hai qualche consiglio per risolverlo?

Quello che sta succedendo è che la tua applicazione e / o gli ApplicationSpawner si stanno chiudendo a causa del timeout. Per elaborare la tua nuova richiesta, Passenger deve avviare una nuova copia dell'applicazione, che può richiedere diversi secondi, anche su una macchina veloce. Per risolvere il problema, ci sono alcune opzioni di configurazione di Apache che puoi usare per mantenere in vita la tua applicazione.

Ecco cosa ho fatto nello specifico sui miei server. PassengerSpawnMethod e PassengerMaxPreloaderIdleTime sono le opzioni di configurazione più importanti nella tua situazione.

# 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

Utilizzando la modalità di generazione "intelligente" e disattivando PassengerMaxPreloaderIdleTime, Passenger manterrà in memoria 1 copia della tua applicazione in ogni momento (dopo la prima richiesta dopo l'avvio di Apache). I singoli Applicationascoltatori verranno modificati forkda questa copia, che è un'operazione super economica. Succede così velocemente che non puoi dire se la tua applicazione ha dovuto generare o meno un ascoltatore.

Se la tua app non è compatibile con lo spawning intelligente, ti consiglio di tenere un PassengerPoolIdleTime di grandi dimensioni e di colpire periodicamente il tuo sito usando curl e un cronjob o monit o qualcosa del genere per assicurarti che l'ascoltatore rimanga in vita.

La Guida per l'utente del passeggero è un ottimo riferimento per queste e altre opzioni di configurazione.

modifica : se la tua app non è compatibile con lo spawning intelligente, ci sono alcune nuove opzioni che sono molto belle

# 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

Quindi, se combini PassengerPreStart e PassengerMinInstances, Passenger eseguirà 3 istanze immediatamente dopo il caricamento di apache e manterrà sempre almeno 3 istanze, quindi i tuoi utenti raramente (se non mai) vedranno un ritardo.

Oppure, se stai già utilizzando lo spawning intelligente (consigliato) PassengerMaxPreloaderIdleTime 0, puoi aggiungerlo PassengerPreStartper ottenere l'ulteriore vantaggio dell'avvio immediato.

Mille grazie agli eroi di phusion.nl !

Solo nel caso in cui ci siano utenti di server nginx che si imbattono in questa domanda, entrambe le direttive "PassengerMaxRequests" e "PassengerStatThrottleRate" non si traducono in nginx. Tuttavia gli altri lo fanno:

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

HTH!

EDIT rails_spawn_methodè deprecato nel passeggero 3 invece di utilizzare

passenger_spawn_method smart; 

tutto il resto è solo buono fino alla data.

Puoi anche utilizzare PassengerMinInstances:

http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerMinInstances

Questo può essere combinato con PassengerPreStart

RI:

# 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 qualcosa da aggiungere e potrebbe essere utile.

Il metodo di spawn predefinito nella versione corrente è "smart-lv2", che salta lo spawner del framework, quindi l'impostazione del timeout dello spawn del framework non avrebbe comunque effetto a meno che non si imposti esplicitamente il metodo di spawn su "smart".

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

Se il tuo host è un server condiviso, come il mio, non puoi modificare le impostazioni e sei bloccato con un cron job.

Ho avuto anche questo problema ma non sono stato in grado di modificare le impostazioni del passeggero perché non avevo il permesso di scrittura su questo file. Ho trovato uno strumento ( http://www.wekkars.com ) che fa sì che la mia app risponda rapidamente. Forse questa può essere anche una soluzione per te.

controlla la versione del passeggero. era RailsSpawnMethod <string>per le vecchie versioni.

Se è così (se non ricordo male), sostituisci Passenger con Rails in tutte le direttive di configurazione o cerca i vecchi documenti dei passeggeri per maggiori dettagli