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.
12 Comentários
Trackbacks
- Elvis Fernandes » Blog Archive » Instalando o Mongrel no Debian
- blog.adsystems.com.br » WEBrick, Apache, lighttpd ou Mongrel?
Eu uso mongrel em casa, para densevolvimento..
para produção eu ainda estou em dúvida em qual manter….
no momento, a unica aplicação minha online, ta utilizando Mongrel com 1 instancia soh…..
;/
Eu uso o Mongrel em casa e para projetos pessoais também. Mas tenho alguns projetos usando Apache em produção.
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.
Oops, eu quis dizer Apache 2.2 e não 2.1.
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).
Acho que a boa combinação é o Apache na frente como balanceamento de carga e Mongrel.
Se bem que nunca coloquei um projeto em produção com essa configuração, apenas o Apache com FastCGI e mesmo assim não tenho reclamações.
Akita e os seus 2 centavos (que na verdade valem muitos reais)…
Akita, obrigado pelos comentários, é uma verdadeira aula sobre servidores para Rails.
Eu quis colocar da forma mais simples possível as principais diferenças entre os principais servidores para Rails. E confesso que nem conhecia o Nginx. Prometo que vou estudá-lo (sou curioso pacas) e conferir as informações que você passou.
Valeu pelas informações extras.
Samir, alguns de meus clientes tem usado Apache com FastCGI também e até hoje não tive nenhuma reclamação, mesmo para sites com muitos acessos simultâneos.
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.
Carlos,
Acho que faltou você mencionar também que é possivel hospedar o Rails com o IIS da Micro$oft :)
É verdade… o IIS também pode rodar Rails… daquele jeito…
pelo amor de Deus né, só um doido ou muito fã da Mico$oft para hospedar um site no Ruindow$.
programa com ruby on rails no windows já é uma batalha, ainda hospedar…… o cara tem que ser muito corajoso
To gostando do “Thin” – http://code.macournoyer.com/thin/