Webrick come server di produzione contro Thin o Unicorn?

117

Sembra che sia scontato che non devi usare Webrick come server di produzione, ma non riesco a trovare da nessuna parte che ne menzioni il motivo. Il consenso sembra essere: "Webrick va bene per lo sviluppo, ma Thin o Unicorn è la scelta per la produzione, punto."

Ho cercato la home page del server Thin e parla di richieste / secondo ma non capisco davvero il grafico poiché non ci sono annotazioni.

Qualcuno può farmi sapere perché dovrei usare Thin o Unicorn rispetto a Webrick? Inoltre, c'è qualche vantaggio nell'usare Webrick per lo sviluppo? Uso Webrick da quando viene fornito con i binari e penso che dovrebbe esserci un motivo per cui è predefinito.

A proposito, sto usando Heroku.

— Vlad
fonte

È lento rispetto ad altri come Mongrel.

— uday

38

Ken, davvero non ho fatto questa domanda per discutere di nulla. Voglio sinceramente sapere la risposta perché non sono riuscito a trovare statistiche reali da nessuna parte, quando tutti danno per scontato che Webrick sia inferiore. Non sono affiliato a nessuna di quelle parti e i dibattiti che hai citato sono domande che pongo per genuina curiosità. Come posso riformulare la domanda in modo che non appaia in questo modo?

— Vlad

24

Questa è una buona domanda.

— justingordon

29

Domande come questa NON dovrebbero essere chiuse. Sono utili e di aiuto. Tutta la polizia dei contenuti auto-nominata dovrebbe fare marcia indietro.

— Ken Smith

22

L'ho trovato cercando su Google "Perché non utilizzare WEBrick in produzione?" perché è una domanda a cui voglio rispondere. Non intendo usare WEBrick nella produzione, ma trovo fastidioso che tutti dicano: "Perché non è For Production®, ovviamente". Non è davvero così ovvio: se lo fosse, le persone non farebbero ricerche sulla domanda prima di chiedere finalmente su StackOverflow, come @Vlad indica che ha fatto. La risposta accettata è utile; sottolinea almeno alcune caratteristiche mancanti. Tangenzialmente, insistere sul fatto che una domanda sia chiusa perché pensi che sia discutibile senza fornire la tua risposta non è utile.

— Justin Force

42

Un paio di ragioni importanti

è scritto in Ruby (vedi http://github.com/ruby/ruby/tree/trunk/lib/webrick )
Modificato , non ha molte funzionalità di cui un sito Web di produzione ha solitamente bisogno, come più worker (in particolare, pre-fork, gestione del ciclo di vita, gestione asincrona, ecc.), Reindirizzamenti, riscrittura, ecc.

Quando parlo di reindirizzamenti / riscritture, mi riferisco al fatto che usando Webrick, devi gestire le riscritture a un livello diverso (Rack, Sinatra, Rails, codice Webrick personalizzato, ecc.). Ciò richiede di attivare "gestori" ruby extra per eseguire il codice di riscrittura. Per un sito a basso traffico, questo può andare bene in quanto potresti avere processi preriscaldati che non fanno già nulla. Tuttavia, per un sito con traffico più elevato, questo è un carico aggiuntivo sul server per qualcosa che i server front-end (Apache, Nginx, ecc.) Possono gestire senza far girare Ruby * e probabilmente più velocemente di ordini di grandezza.

* ad esempio, se stai utilizzando un sistema di bilanciamento del carico, potresti instradare tutto il traffico di riscrittura a un server su cui non è installato ruby e lasciare che i tuoi server principali gestiscano solo il traffico principale. Questo traffico di riscrittura potrebbe essere dovuto a modifiche del sito per SEO o qualcosa di simile. Un altro caso potrebbe essere un sito che ha più componenti, e forse una sezione è Rails, un'altra è PHP, e le riscritture sono necessarie per entrambi (cioè riscrivere i vecchi percorsi PHP su Rails)

— Jim Deville
fonte

Non è possibile utilizzare delayed_job per gestire più worker su Heroku, indipendentemente dal server che utilizzi?

— Vlad

Sì, delayed_job non è correlato a Webrick, a meno che i tuoi lavori non utilizzino le API Webrick (che onestamente è un odore di codice mentre si accoppia).

— Jim Deville

Mi riferisco ai reindirizzamenti al di fuori dello stack Ruby. Come i reindirizzamenti in stile mod_rewrite. Tecnicamente, puoi reindirizzare all'interno di Rack, o Rails, o, forse anche Webrick (potrei sbagliarmi), ma ciò richiede l'avvio di Ruby, che è relativamente lento rispetto ad Apache o Nginx

— Jim Deville

1

@JimDeville - Unicorn è anche scritto in Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_http una grande porzione di Unicorn è in C

— Jim Deville

4

WEBrick inoltre non può gestire URI più lunghi, se superano i 2083 caratteri vedrai un arresto anomalo. Thin non ha questi problemi, il che lo ha reso superiore - già in fase di sviluppo.

— Michael Schmitz
fonte

Anche Webrick ha perso la connessione e si è spento automaticamente quando, per esperienza, sto sviluppando software e quando ho scelto WeBRICK in Heroku PaaS, lo spegnimento automatico è compensato dall'elevata velocità di accensione automatica (attivata automaticamente dall'architettura di Heroku )

— Daniel Antonio Nuñez Carhuayo

3

Non mi piace molto complicare le cose semplici e l'ottimizzazione prematura. WEBrick può essere utilizzato in produzione a condizione che sia un sito Web a basso traffico. La maggior parte delle applicazioni lo sono.

Se il tuo sito fa qualcosa che richiede tempo, ad esempio invia e-mail o genera file PDF, dovresti rendere WEBrick multi-thread . Vuoi gestire più richieste alla volta.

— Nowaker
fonte

1

Ha avuto alcuni problemi di sicurezza in passato, ma sembra che il motivo principale sia che è molto lento rispetto ai server destinati alla produzione.

— Brett Henning
fonte

4

Hai visto un confronto delle statistiche? Ho anche sentito persone che lo dicono (ed è probabilmente vero) ma non riesco a trovare un vero confronto statistico ovunque sul web ...

— Vlad

3

Non credo che nessuno faccia un benchmark reale su Webrick perché non è pensato per essere un server di produzione. Unicorn, Thin o Passenger sono opzioni ben supportate e molto migliori

— Jim Deville

0

Il più grande punto debole di webrick quando viene eseguito in modalità di produzione è che è un server web a thread singolo e processo singolo, il che significa che è in grado di servire solo una singola richiesta http alla volta.

— Artur Beljajev
fonte

Non è single threaded. Oppure è nello stesso modo in cui viene implementato qualsiasi linguaggio di scripting moderno (con un GIL). Ma l'accesso al database e l'IO in webrick sono completamente multithread.

— Lothar