Webrick como servidor de produção vs. Thin ou Unicorn?

117

Parece que é um dado adquirido que você não deve usar o Webrick como servidor de produção, mas não consigo encontrar nenhum lugar mencionando o porquê. O consenso parece ser: "Webrick está bem para desenvolvimento, mas Thin ou Unicorn é a escolha para produção, ponto final."

Eu pesquisei a página inicial do Thin server e ela fala sobre solicitações / segundo, mas eu realmente não entendo o gráfico, pois não há anotações.

Alguém pode me dizer por que devo usar Thin ou Unicorn em comparação com Webrick? Também há algum benefício em usar o Webrick para desenvolvimento? Tenho usado o Webrick desde que vem com rails, e acho que deve haver uma razão para ele ser padrão.

A propósito, estou usando o Heroku.

— Vlad
fonte

É lento quando comparado a outros como Mongrel.

— dia

38

Ken, eu realmente não fiz essa pergunta para debater nada. Eu realmente quero saber a resposta porque não consegui encontrar estatísticas reais em lugar nenhum, quando todos consideram que Webrick é inferior. Não sou afiliado a nenhum desses partidos e os debates que você mencionou são perguntas que faço por genuína curiosidade. Como posso reformular a pergunta para que não pareça assim?

— Vlad

24

Essa é uma boa pergunta.

— Justingordon

29

Perguntas como esta NÃO devem ser fechadas. Eles são úteis e úteis. Todos os policiais de conteúdo autodesignados devem recuar.

— Ken Smith,

22

Eu encontrei isso pesquisando no Google "Por que não usar o WEBrick na produção?" porque é uma pergunta que quero respondida. Não pretendo usar WEBrick na produção, mas acho irritante que todos digam: "Porque não é para a produção®, obviamente." Realmente não é tão óbvio - se fosse, as pessoas não estariam pesquisando a questão antes de finalmente perguntar no StackOverflow, como @Vlad indica que ele fez. A resposta aceita é útil; pelo menos aponta alguns recursos ausentes. Tangencialmente, insistir para que uma pergunta seja encerrada porque você a considera discutível sem fornecer sua própria resposta não ajuda.

— Justin Force

42

Algumas razões importantes

está escrito em Ruby (consulte http://github.com/ruby/ruby/tree/trunk/lib/webrick )
Editado , não tem muitos recursos que um site de produção geralmente precisa, como vários trabalhadores (em particular, pré-bifurcação, gerenciamento de ciclo de vida, manuseio assíncrono, etc), redirecionamentos, reescrita, etc

Quando menciono redirecionamentos / reescritas, estou me referindo ao fato de que usando o Webrick, você tem que lidar com reescritas em uma camada diferente (Rack, Sinatra, Rails, código Webrick personalizado, etc). Isso requer que você gire "manipuladores" extras de ruby para executar seu código de reescrita. Para um site de baixo tráfego, isso pode ser bom, pois você pode ter processos pré-aquecidos sem fazer nada. No entanto, para um site de tráfego mais alto, isso é uma carga extra no servidor para algo que os servidores front-end (Apache, Nginx, etc) podem lidar sem girar Ruby *, e provavelmente ordens de magnitude mais rápido.

* por exemplo, se você estiver executando atrás de um balanceador de carga, poderá rotear todo o tráfego de reescrita para um servidor que não tenha o Ruby instalado e permitir que seus servidores principais gerenciem apenas o tráfego primário. Esse tráfego de reescrita pode ser devido a alterações do site para SEO ou algo semelhante. Outro caso seria um site que tem vários componentes, e talvez uma seção seja Rails, outra é PHP, e reescrita é necessária para ambos (ou seja, reescrever caminhos antigos de PHP para Rails)

— Jim Deville
fonte

Não é possível usar delayed_job para lidar com vários trabalhadores no Heroku, independentemente de qual servidor você usa?

— Vlad

Sim, delayed_job não está relacionado ao Webrick, a menos que seus trabalhos usem APIs do Webrick (que, honestamente, é um cheiro de código que acopla).

— Jim Deville

Estou me referindo a redirecionamentos fora da pilha Ruby. Como redirecionamentos de estilo mod_rewrite. Tecnicamente, você pode redirecionar dentro do Rack, ou Rails, ou talvez até Webrick (eu posso estar errado), mas isso requer o início do Ruby, que é comparativamente lento vs Apache ou Nginx

— Jim Deville

1

@JimDeville - Unicorn também é escrito em Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_http uma grande parte do Unicorn está em C

— Jim Deville

4

WEBrick também não pode lidar com URIs mais longos, se eles excederem 2083 caracteres, você verá uma falha. Thin não tem esses problemas, o que o torna superior - já em desenvolvimento.

— Michael Schmitz
fonte

Além disso, o Webrick perdeu a conexão e desligou automaticamente quando, por experiência própria, estou desenvolvendo software e quando escolhi o WeBRICK no Heroku PaaS, o desligamento automático é compensado pela alta velocidade de ligação automática (acionada através da arquitetura automática do Heroku )

— Daniel Antonio Nuñez Carhuayo

3

Eu realmente não gosto de complicar coisas simples e otimização prematura. WEBrick pode ser usado na produção, desde que seja um site de baixo tráfego. A maioria dos aplicativos é.

Se o seu site faz algo que leva tempo, por exemplo, enviar e-mails ou gerar arquivos PDF, você deve tornar o WEBrick multi-threaded . Você deseja lidar com várias solicitações ao mesmo tempo.

— Nowaker
fonte

1

Ele teve alguns problemas de segurança no passado, mas parece que o grande motivo é que ele é muito lento em comparação com os servidores destinados à produção.

— Brett Henning
fonte

4

Você viu uma comparação de estatísticas? Eu também ouço pessoas dizendo isso (e provavelmente é verdade), mas não consigo encontrar uma comparação de estatísticas reais em qualquer lugar da web ...

— Vlad

3

Eu não acho que alguém realmente faça benchmarks do Webrick porque ele não se destina a ser um servidor de produção. Unicorn, Thin ou Passenger são bem suportados e opções muito melhores

— Jim Deville

0

A maior fraqueza do webrick quando executado em modo de produção é que ele é um servidor da web de processo único e thread único, o que significa que é capaz de atender a apenas uma solicitação http de cada vez.

— Artur Beljajev
fonte

Não é de segmento único. Ou é da mesma forma que qualquer linguagem de script moderna é implementada (com um GIL). Mas o acesso ao banco de dados e IO no webrick é totalmente multithread.

— Lothar