2009-05-12 13 views
84

Per saltare sul carro della band di Phusion Passenger abbiamo installato un server di staging per un'app per le piccole rotaie per testare le cose.Avvio lento del server iniziale quando si utilizza Phusion Passenger e Rails

Finora è stato molto bello da usare, rende l'installazione/configurazione e distribuzione di applicazioni un gioco da ragazzi. Il problema è che il sito che stiamo usando non viene colpito molto spesso e sembra chiudere i server in background. Significa che quando qualcuno visita il sito ha un'attesa molto lunga fino all'avvio di un nuovo server per gestire la richiesta. Abbiamo letto la documentazione, provato diversi set-up (modalità smart/smart-lv2, passeggero ecc.) E non abbiamo ancora trovato una soluzione reale.

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

Qualcun altro ha riscontrato questo problema e hai qualche consiglio per una correzione?

+0

Ho trovato anche questo nugget sul sito Doc Passenger: http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerPreStart – dewrich

+0

@dewrich Ho trovato uno strumento (http://wekkars.com) che fa esattamente ciò che sta facendo il tuo cronjob – SteenhouwerD

risposta

114

Che cosa sta succedendo è che l'applicazione e/o ApplicationSpawners si chiudono a causa del timeout. Per elaborare la tua nuova richiesta, Passenger deve avviare una nuova copia della tua 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 viva la tua Applicazione.

Ecco in particolare ciò che ho fatto 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 riproduzione "intelligente" e spegnendo PassengerMaxPreloaderIdleTime, Passeggero manterrà 1 copia della vostra applicazione nella memoria in ogni momento (dopo la prima richiesta dopo l'avvio di Apache). Gli ascoltatori singoli Application saranno fork da questa copia, che è un'operazione super-economica. Succede così rapidamente che non puoi dire se la tua applicazione ha dovuto generare un listener.

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

Il Passenger User Guide è un riferimento eccezionale per queste e più opzioni di configurazione.

modificare: Se la vostra applicazione non è compatibile con intelligente deposizione delle uova, ci sono alcune nuove opzioni che sono molto bello

# 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 si combinano PassengerPreStart e PassengerMinInstances, Passeggero sarà spin up 3 istanze immediatamente dopo il caricamento di apache e manterranno sempre almeno 3 istanze in su, quindi gli utenti raramente (se mai) vedranno un ritardo.

Oppure, se si utilizza Smart spawning (consigliato) con PassengerMaxPreloaderIdleTime 0, è possibile aggiungere PassengerPreStart per ottenere il vantaggio aggiuntivo di avvio immediato.

Mille grazie agli eroi allo phusion.nl!

+0

Grazie mille per la tua risposta. Credo che abbiamo provato la maggior parte di quelle impostazioni ma forse non nella combinazione corretta. Domani effettuerò dei test e tornerò. – tsdbrown

+0

Questo è fantastico. Stavo avendo lo stesso problema con la mia installazione Nginx/Phusion Passenger e questo mi ha aiutato moltissimo. –

+0

Ho provato questa configurazione e non vedo miglioramenti delle prestazioni, ma la nostra app utilizza RMagick. Ci sono soluzioni alternative per questo? Perché non funziona con RMagick? –

1

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

+0

Per questa particolare applicazione fortunatamente non lo è. Ma lo terrò a mente per il futuro, grazie. – tsdbrown

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 una cosa da aggiungere e potrebbe essere utile.

Il metodo predefinito di spawn nella release corrente è "smart-LV2", che salta lo spawner quadro, in modo da impostare il timeout quadro spawner non avrebbe effetto in ogni caso a meno che non impostare in modo esplicito il metodo di spawn a "intelligente ".

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

38

Solo in caso ci siano gli utenti del server nginx inciampo su questa domanda, sia le 'PassengerMaxRequests' e direttive 'PassengerStatThrottleRate' non si traducono a nginx. Tuttavia gli altri 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 in passeggero 3 invece utilizzare

passenger_spawn_method smart; 

tutto il resto è solo buono fino a data.

+7

Grazie per questo. Una cosa da notare è che ho dovuto riempire il passeggero_pool_idle_time nel mio nginx.conf principale con le altre impostazioni globali invece di solo nella specifica configurazione del sito in cui le rotaie erano abilitate. –

+0

ma errore del passeggero 4: ' "passenger_max_preloader_idle_time" direttiva è duplicate – TangMonk

4

È inoltre possibile utilizzare PassengerMinInstances:

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

Questo può essere combinato con PassengerPreStart

+0

Dalla documentazione: "È necessario impostare questa opzione a un valore diverso da zero se si vuole evitare i tempi di avvio lunghi potenzialmente dopo un sito web è rimasto inattivo per un prolungato periodo." Sembra la risposta perfetta per la domanda dell'OP. – Chuck

0

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

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

1

ho avuto anche questo problema, ma non ero 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 consente alla mia app di rispondere velocemente. Forse questo può anche essere una soluzione per te.

Problemi correlati