Feed Artigos Comentários


TI André Dourado em 18 dez 2008

WEBrick, Apache, lighttpd ou Mongrel?

Por Carlos Brando em 25 de Setembro de 2007

Diante de tantas opções, não é fácil para um desenvolvedor RoR escolher o melhor servidor web para o seu software. Resolvi criar este post para tentar explicar de uma forma simples e rápida as diferenças entre os principais servidores web que suportam Rails.

WEBrick
Padrão. Se tivesse de resumir este servidor em apenas uma palavra, a palavra seria: padrão. É o servidor que “vem” com o Rails. Ele é escrito em Ruby e por isto é fácil integra-lo com o Rails, pois ele pode fazer chamadas diretas ás suas aplicações.

Em minha opinião é a opção mais simples e rápida de se usar.

Apache
O Apache é o servidor web mais usado no mundo. É a opção mais escalável e flexível para projetos Rails. Possui plugins que permitem que o servidor funcione com dezenas de linguagens de programação diferentes. Também suporta balanceamento de carga e sprayes de uma forma bem robusta.

Em outras palavras é a opção mais segura.

lighttpd
Velocidade é a palavra que estava na mente dos criadores do lighttpd. Ele foi criado com este objetivo em mente. Não chega perto da flexibilidade oferecida pelo Apache, mas faz o serviço direitinho e muito mais rápido. Pode rodar softwares produzidos em RoR por meio de uma interface FastCGI.

lighttpd é o papa-léguas dos servidores web para Rails.

Mongrel
O Apache é mais escalável e o lighttpd é o mais rápido, mas fazê-los funcionar com o Rails com certeza não uma tarefa das mais triviais. Mas fazer uma aplicação Rails rodar no Mongrel é extremamente simples e trivial.

O Mongrel é tão simples de usar quanto o WEBrick, pois também é escrito em Ruby e foi construído com o mesmo conceito do lighttpd em mente: velocidade. Talvez por este motivo ele seja o queridinho da comunidade RoR.

Outras opções
É claro que existem outros servidores web que podem ser utilizados para suportar uma aplicação em Ruby on Rails, na verdade qualquer servidor que suporte CGI pode fazer isto. Mas esses quatro são os mais usados hoje em dia.

Comentários do Fábio Akita no Post Original

AkitaOnRails 25/09/2007
Meus 2 centavos: a combinação mais “rápida” (depende de como o aplicativo é feito e usado) é usar nginx (no lugar de Apache ou Lightpd como load balancer) na frente de mongrel_cluster controlando alguns processos mongrel atrás – Monit e Swiftiply podem ser considerados.

Fazer offload de processos demorados usando BackgroundRB ou em alguns casos particionar o aplicativo e colocar módulos mais pesados (como serviços) em Merb. Usar cache de objetos ActiveRecord muito utilizados em memcached e usar o suporte de cache do Rails (page, fragment). Sem contar ter um MySQL bem otimizado, com as tabelas devidamente indexadas conforme as queries que ele atende.

Apesar de alguns hosts ainda usarem, Lightpd eu vejo muito pouco. Webrick também não é mais usado porque desde o Rails 1.1 o script/server por default escolhe Mongrel – sinceramente não vejo nenhum motivo para usar Webrick. Em produção, para aplicativos muito pouco usados, mesmo assim é recomendável Apache 2.1 com mod_proxy_balancer na frente de um mongrel_cluster com – no mínimo do mínimo – 2 processos mongrel.

Usuários de Ubuntu Dapper (que muitos hostings oferecem) ou abaixo estão sem sorte pois o Apache default é o 2.0, que não oferece o mod_proxy_balancer. Mas existe uma maneira de usar o mod_proxy original para fazer um load balancing round robin. Quem não se importar de perder atualizações via apt-get, pode gostar de usar Deprec, que é um conjunto de scripts que pega um Ubuntu Dapper zerado e instala tudo que você precisa para rodar Rails, incluindo SSH, Apache 2.1, Mongrel, etc.

Recomendo procurar a Rails Machine para pacotes completos de deployment de Rails para sua máquina.

AkitaOnRails 25/09/2007
Oops, eu quis dizer Apache 2.2 e não 2.1.

AkitaOnRails 25/09/2007
Eita, devia ter pensado melhor antes de enviar o 1o comentário Esqueci de falar: o importante do que fica na frente do Mongrel é o fato de ser um Proxy Reverso HTTP rápido. Para isso Apache+mod_proxy_balance, Lightpd (que já tem balancer embutido) funcionam. Mas existem muitas instalações com Lightspeed, Pen, Pound, Haproxy ou Swiftply (que um Mongrel modificado). Eu disse que Lightpd não é muito usado porque ele era bom na época de FCGI, quando ainda não existia Mongrel. Desde então ele passou de ser usado. Apache 2.2+mod_proxy_balance é o mais conhecido e mais utilizado, mas como Proxy Reverso qualquer dos anteriores é bom: quanto mais leve melhor, por isso agora a consideração por nginx que é um servidor HTTP russo muito leve. Recomendo acompanhar Ezra quando procurar por performance. Pen, Pound e Haproxy tem vários defeitos (listei porque existem muitos tutoriais na web sobre eles). Nginx é o mais recomendado se precisar do maximo de performance. Apache 2.2 é mais recomendado para quem já sabe usar e não quiser arriscar. Mas Ezra definitvamente recomenda o pacote Nginx+Mongrel (atualmente ainda estou com Apache+Mongrel).

AkitaOnRails 25/09/2007
Blz, então meu próprio blog no Railsplayground ainda está em FCGI, eu nem me incomodei em mudar porque realmente não está precisando. Mas se eu fosse colocar numa empresa (depende do tamanho e do uso) talvez eu já pensasse em colocar algo mais escalável. A vantagem de usar algo como Swiftply é que num dia de muito uso (se por exemplo for um app que faz parte do processo de fechamento numa empresa, ou se for um app. de RH e for dia de tirar um holerith online, coisas assim) você pode monitorar e subir Mongrels na mesma máquina ou em máquinas paralelas sem precisar parar o aplicativo. A idéia é muito boa. O Nginx é se você realmente precisar da performance extra. A vantagem de usar Apache é que ele tem uma comunidade muito maior e o suporte é mais simples do que qualquer outra alternativa. Não usar Mongrel, em instalações novas hoje, não há porque não. A pergunta é só quem será o load balancer e qual será a estratégia de cluster. Meu problema com o Webrick é que se alguém que está começando tentar usá-lo, pode achar que ele serve para produção, e realmente não há motivos para isso. Mesmo em Windows você instala um mongrel_service e ele inicia como serviço do Windows. É melhor nem mencionar que Webrick existe Lightpd acho que a 37signals ainda usa, mas é de uma época quando o Apache não tinha bom suporte a FCGI – vale lembrar: FCGI e Mongrel(HTTP) são métodos concorrentes. FCGI é um pouco mais rápido, mas o gerenciamento é pior, Mongrel é um pouco menos rápido mas o gerenciamento é mais prático. Dynamic FCGI (que meu hosting usa) derruba processos Rails quando não estão sendo usados. Eu acho isso horrível pois subir um novo Rails é demorado, em um projeto interno isso não faz nenhum sentido. Outra coisa: Mongrel tem memory leak, isso é inevitável e mais do que isso: ele pode morrer. Algumas extensions são em C, não vamos esquecer e nem sempre eles vão rodar 100%. Para não perder os cabelos quando seu sistema cair no meio da noite, recomendo instalar Monit para monitorar seus mongrels e restartá-los. Normalmente o Apache não cai, é muito difícil, mas Mongrel – principalmente se você estiver rodando extensions pesadas em C, pode cair.

Fonte: Nome do Jogo

Post visualizado 374 vezes.

2 Comentários para “WEBrick, Apache, lighttpd ou Mongrel?”

  1. em 05 jan 2009 às 17:57 1.Cleber escreveu …

    Andre,

    Boa tarde,

    Inseri o mongrel como serviço de WEB do redmine, até então, blz, fiz os testes na minha máquina (SO Win XP) e funcionou normalmente, joguei no servidor (SO Win 2003 Server) e também funcionou normalmente, até a hora em que se reicia o servidor. Nos testes que fiz em minha máquina levantou normalmente mesmo sem eu me logar, agora quando reinicio o servidor ele levanta, mas da erro ai eu tenho que entrar com o login e restartar o serviço do mongrel criado por mim, você pode me ajudar? inclusive criei um serviço para o Instant Rails e como informei na minha máquina sobe tudo normalmente, mas no servidor tenho que reiniciar o serviço do Mongrel.

    Abraços,

    Cleber

  2. em 05 jan 2009 às 22:10 2.André Dourado escreveu …

    Grande Cleber,

    eê uma olhada no log de aplicações do Windows 2003. Iniciar > Configurações > Painel de Controle > Ferramentas Administrativas > Visualizar Eventos. Clique em Aplicativos e procure pelo “Erro” ou algo relativo ao serviço.

    Me mande o erro informado.

    []s

    André Dourado

Trackback esse post | Subscreva os comentários pelo RSS Feed

Deixe um comentário