2009-11-13 5 views
14

Molto presto ho in programma di implementare la mia prima applicazione Ruby on Rails in un ambiente di produzione e ho persino scelto un webhost con tutti i server gestiti e Capistrano bontà te ' d aspettarsi da un fornitore di RoR.Consigli (e differenze) tra diversi server Web di produzione di Ruby on Rails

Il provider consente i server Web FastCGI di Mongrel, Thin, Passenger &, che sembra molto flessibile, ma onestamente non conosco le differenze tra loro. Ne ho esaminati alcuni, ma tutto diventa un po 'eccessivo quando iniziano a parlare di funzionalità e di richieste simultanee massime - e questo dato sembra variare a seconda di chi lo pubblica.

Ho guardato il Passeggero (in superficie) - che mi sembra molto attraente - ma avevo l'impressione che Passenger non fosse il server web effettivo, e invece era più simile a uno strato sopra Apache o nginx e istanze generate generate dall'applicazione (come un cluster Mongrel).

Qualcuno può impostare me dritto con le differenze in termini profani in modo che posso scegliere con saggezza (perché chiunque abbia visto Indiana Jones e l'ultima crociata sa che cosa succede se si sceglie male).

+1

Questo collegamento potrebbe essere utile: http://tenmiles.com/blog/2010/08/apache-passenger-and-other-server-alternatives-rails/ –

risposta

33

Risposta breve

Go con Apache/Nginx + passeggero. Passeggero is fast, affidabile, facile da configurare e distribuire. Il passeggero è stato adottato da un gran numero di grandi applicazioni Rails, tra cui Shopify.

alt text http://www.modrails.com/images/passenger_mongrel_thin_benchmark.png

La risposta lunga

Dimenticate CGI e FastCGI. All'inizio non c'erano altre alternative quindi l'unico modo per eseguire Rails era usare CGI o il browser FastCGI più veloce. Oggigiorno quasi nessuno gestisce Rails sotto CGI. Le ultime versioni di Rails non forniscono più corridori .cgi e .fcgi.

Mongrel è stata una soluzione ampiamente adottata, il miglior sostituto per CGI e FCGI. Molti siti usano ancora il cluster Mongrel e Mongrel, tuttavia il progetto Mongrel è quasi morto e molti progetti sono già stati spostati su altre soluzioni (principalmente Passenger). Inoltre, un'architettura basata su Mongrel è piuttosto difficile da configurare perché richiede un proxy di frontend (thin, ngnix) e un'architettura backend composta da più istanze di Mongrel.

Da quando è stato rilasciato, il passeggero ha acquisito grande attenzione. Molti progetti sono passati da Mongrel a Passenger per molte ragioni, tra cui (ma non solo) facilità di implementazione, manutenzione e prestazioni. Inoltre, Passenger è ora disponibile sia per Apache che Ngnix.

Il modo più semplice per utilizzare Passenger è la configurazione Apache + Passenger. Un'installazione Apache e più processi Passenger.

Se sono necessarie prestazioni e scalabilità migliori, è possibile utilizzare Ngnix come proxy di frontend e inoltrare tutte le richieste di Rails a più server di back-end, ciascuno composto da Apache + Passenger. Non sto andando nei dettagli tecnici qui, questa soluzione è pensata per essere utilizzata dai progetti Rails con un alto livello di traffico.

Ancora più soluzioni complesse includono una combinazione di diversi livelli tra cui proxy e server http.Puoi avere un'idea di cosa sto parlando leggendo alcuni dettagli interni da GitHub e Heroku.

In questo momento, Passenger è la migliore risposta per la maggior parte dei progetti Rails.

+1

Risposta eccellente. –

9

Mongolo e Thin sono server di processo a ruby ​​singolo che verranno eseguiti in cluster multipli dietro un tipo di proxy (come Apache o Nginx). Il proxy gestirà quale istanza di Mongrel o Thin elabora le richieste.

Passenger crea un'interfaccia tra Apache o Nginx che crea un processo di spawning delle applicazioni e quindi avvia i processi per eseguire il server delle richieste in arrivo non appena arrivano. Esistono molte opzioni di configurazione per quanto tempo durano quei processi, quanti lì ci sono può essere, e quante richieste serviranno prima che muoiano. Questo è di gran lunga il modo più comune per scalare e gestire un'applicazione ad alto traffico, ma non è privo di inconvenienti. Questo può essere fatto solo su un sistema operativo * nix (linux, mac os x, ecc.). Inoltre, questi processi si attivano a richiesta, quindi se nessuno accede al tuo sito per un po 'di tempo, i processi vengono eliminati e la richiesta successiva ha il ritardo di riavviarsi. Con Mongrel e Thin, il processo è sempre in esecuzione. A volte però, i processi nuovi e freschi possono essere una buona cosa per l'utilizzo della memoria ecc.

Se si tratta di un sito a traffico relativamente basso, Mongrel o Thin fornisce un modo semplice e facile da gestire per distribuire l'applicazione . Per i siti di traffico più elevati in cui è necessario l'accodamento intelligente e la gestione dei processi di qualcosa come Passenger, è un'ottima soluzione.

Per quanto riguarda fastcgi, probabilmente si desidera utilizzarlo come ultima opzione.

1

Io uso Passenger + nginx. Funziona davvero, davvero bene.

1

Per ottenere prestazioni istantanee vantate dai passeggeri, consiglio di utilizzare l'edizione aziendale di ruby.