Thin vs Unicorn su Heroku

Question

Volevo solo ottenere le opinioni della gente sull'utilizzo di Unicorn vs Thin come server di rotaie. La maggior parte degli articoli/benchmark che ho trovato online sembrano molto incompleti, quindi sarebbe bello avere un posto centralizzato per discuterne.

Unicron è un server multiprocesso, mentre thin è un server basato su eventi/non bloccante. I server basati su eventi sono grandiosi ... se il tuo codice è asincrono/non bloccante, i binari di vaniglia stanno bloccando. Quindi, a meno che non si utilizzino librerie di rails non bloccanti, non vedo davvero il vantaggio dell'uso di Thin. Ancora peggio, in un server non bloccante, se il tuo loop di I/O sta bloccando, bloccherai l'intero ciclo e non sarai in grado di gestire altre richieste fino a quando la chiamata di blocco non ritorna. Le librerie di blocchi stanno andando a rallentare!

Perché Heroku ha scelto Thin come server predefinito (per il cedro)? Sono persone intelligenti, quindi sono sicuro che avessero una ragione.

Bellow è un collegamento che suggerisce di sostituire Thin con 4 lavoratori Unicorn - questo ha perfettamente senso per me. 4 Unicron workers on Heroku

Answer 1

Thin è facile da configurare, non ottimale, ma funziona solo nell'ambiente Heroku.

L'unicorno può essere più efficiente, ma deve essere configurato: quanti lavoratori? Preload App? Cosa scegli?

Ho rilasciato le app Unicorn Heroku con gli operatori impostati su 3, 5 e 8 - solo in base alla grandezza di ogni app: quanto codice, quanta memoria è utilizzata e quanto traffico vai a prendere questo numero e devi monitorare nel tempo per assicurarti di aver ottenuto il numero giusto e che la tua app non abbia esaurito la memoria.

precarico false - questo renderà la vostra applicazione si avvia più lentamente, ma quando Unicorn riavvia un lavoratore, questo è 'sicuro' con le connessioni di rete (memcache, Postgres, mongo ecc)

precarico vero - questo è meglio, ma è necessario gestire correttamente le re-connessioni del server nel codice fork pre e post.

Thin non ha nessuno di questi problemi fuori dalla scatola, ma si ottiene solo il processo di esecuzione.

Riassunto: E 'davvero difficile da configurare Unicorn fuori dalla scatola di lavorare bene (o affatto) per tutti, mentre la sottile può solo lavorare per ottenere le persone in esecuzione con un minor numero di richieste di supporto.

Answer 2

Heroku non utilizza il routing intelligente: assegnerà in modo casuale i lavori ai dynos indipendentemente dal fatto che il banco sia occupato. Pertanto, se il tuo banco di prova non è in grado di gestire più lavori contemporaneamente, otterrai latenza (forse una latenza enorme) anche se stai pagando per molti altri dynos gratuiti. "Proprio così - se la vostra applicazione ha bisogno di 80 lanci con un router intelligente, ha bisogno di 4.000 con un router casuale." http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku dice che stanno lavorando su questo, e il loro piano è quello di rendere più facile da usare Unicorn. In pratica dicevano "Oops, non abbiamo notato che questo era un problema per alcuni anni ... e ora che guardiamo, è decisamente un problema per Thin ... quindi suppongo tu debba usare un programma diverso da quello uno che abbiamo spinto per tutto questo tempo. " http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

Dalla spiegazione ufficiale Heroku (secondo link qui sotto):. "Rails, infatti, non supporta ancora affidabile concomitante movimentazione richiesta Questo lascia Rails sviluppatori non sono in grado di sfruttare le capacità di concorrenza aggiuntivi offerti dalla pila Cedar, a meno che non si spostino su un server Web concorrente come Puma o Unicorn.

Le applicazioni di Rails distribuite su Cedar con Thin possono piuttosto rapidamente finire con i problemi di accodamento delle richieste. Poiché il router Cedar non esegue più la coda per conto dell'app, le richieste in coda al banco di prova devono attendere fino a quando il processo di Rails singolo si fa strada attraverso la coda. Molti clienti si sono imbattuti in questo problema e non siamo riusciti ad adottare un approccio migliore per l'implementazione di app Rails su Cedar. "

È interessante notare che i loro strumenti per le prestazioni, tra cui New Relic, non hanno riportato il tempo trascorso in coda banco. http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

Ops.

Answer 3

Recentemente (solo pochi mesi fa) la gente dietro Phusion Passenger aggiungere il supporto a Heroku. Sicuramente si tratta di un'alternativa si dovrebbe provare e vedere se si adatta alle vostre esigenze.

I s lampeggiante veloce anche con 1 banco di lavoro e il calo del tempo di risposta è palpabile. Un semplice Passenger Ruby Heroku Demo è ospitato su github.

I principali vantaggi che i passeggeri sulle richieste di Heroku sono:

• accelerazione patrimoniale statico attraverso Nginx - Non lasciate che il vostro Rubino app servire attivi statici, lasciate Nginx farlo per voi e la vostra applicazione offload per i compiti veramente importanti. Nginx farà un lavoro molto migliore.

• lavoratore più processi - Invece di correre un solo lavoratore su un banco prova, Phusion passeggeri corre lavoratore multiple su un singolo banco prova, utilizzando così le sue risorse al massimo e dare più bang per il dollaro. Questo approccio è simile a quello di Unicorn. Ma a differenza di Unicorn, Phusion Passenger scala dinamicamente il numero di processi di lavoro in base al traffico corrente, liberando così risorse quando non sono necessarie.

• Ottimizzazioni memoria - Phusion Passenger utilizza meno memoria di Thin e Unicorn. Supporta anche la memoria virtuale copy-on-write in combinazione con il precaricamento del codice, facendo in modo che l'app usi ancora meno memoria quando viene eseguita su Ruby 2.0.

• richiesta/risposta buffer - I buffer inclusi richieste e le risposte Nginx, proteggendo così la vostra applicazione contro i client lenti (ad esempio i dispositivi mobili su reti mobili) e migliorando le prestazioni.

• Garbage collection fuori banda - Il garbage collector di Ruby è lento, ma perché disturbare i visitatori con tempi di risposta lunghi? Risolvi questo problema eseguendo la garbage collection al di fuori del normale ciclo di richiesta-risposta! Questo concetto, introdotto per la prima volta da Unicorn, è stato migliorato: Phusion Passenger assicura che solo una richiesta allo stesso tempo sta esaurendo la garbage collection fuori banda, eliminando così tutti i problemi che la raccolta dei rifiuti fuori banda di Unicorn ha.

• Supporto JRuby - L'unicorno è una scelta migliore di Thin, ma non supporta JRuby. Phusion Passenger fa.

Spero che questo aiuti.