Performance!

É… eu sei… “lá vem mais um dizer que linguagens interpretadas são lentas” :P

Eu só queria uma avaliação da Ruby no quesito performance. Alguém tem isso? Ex: 2 vezes mais rápido que C++ :D

Não é para encher o saco, é só para saber mesmo se existe alguma limitação nesse ponto.

Cara, acho isso relativo.

Poisé… eu também acho relativo.

Mas em alguns softwares recebemos especificações do tipo, precisa responder em menos de X milésimos de segundo. É claro, pode-se fazer cache, pools e blá blá blá. O que eu gostaria de saber é no default, usando rails com a produtividade que conhecemos que ele traz, sem qualquer mutreta para agilizar alguma coisa.

Existe? :D

Bem que o RubyOnBr poderia faz uma análise estatística do CMS e do fórum que vcs usam neh? :D Tp.. quanto tempo o server gasta para atender a uma requisição. Assim, já se tem um parâmetro.

Pretendo fazer isso essa semana. O bom é que os logs do Rails são perfeitos pra isso.

Como não estamos rodando ainda com FCGI nem nada do tipo (é Apache2 + CGI, segundo o railsplayground), quero ver qto vai ser o ganho de performance qdo trocarmos para Lighttp + Mongrel, se é que vai haver…

De um jeito ou de outro, assim que conseguir os tempos eu posto.

Galera, o site agora está rodando com Lighttp + Mongrel. Não sei vocês, mas eu percebi um tremendo ganho na velocidade. Tá muito rápido agora.

Já peguei os logs antigos e vou ver se analiso eles essa semana pra postar os tempos com Apache + CGI (que é uma das configurações mais lentas possíveis)

Ronie, que você acha de fazer um tutorialzinho sobre a instalação do Lighttp + Mongrel, juntamente com as estatísticas de performance? Ia ficar interessante!

Opa! Idéia muito boa!

Só que talvez fosse melhor Apache + Mongrel. Já que o pessoal é mais familiarizado com ele. Que você acha?

As estatísticas coloco no ar até o fim de semana.

Pode ser com o Apache, ou até com os dois, já que você já fez com o Lighttp e está recente. :-)
Forcei? :-D Mas é que aí fica de material de referência muito bom.

De acordo! Vou trabalhar nisso. Mas só vai ficar pronto depois do fim de semana :)

Beleza! Aí você faz uma promessa e começa a fazer um montão de tutoriais. :-)

Vou me intrometer de xereta. Exatamente essa questão de performance gerou uma grande polêmica (de novo) na blogosfera internacional de Rails. Veja o resumo no post Joel Spolsky VS Rails que publiquei recentemente.

Não é segredo que Ruby sofre críticas por causa de performance. E de fato, a performance bruta (number crunching) é realmente ruim. Existem diversas coisas que podem melhorar. Eu dediquei um capítulo inteiro no meu livro apenas para discutir essa questão. Em resumo: sim, Ruby é comparativamente mais lento que outras linguagens, incluindo Python e, claro, Java. Não ela não é lenta a ponto de ser inviável. Vejam sites como Basecamp e 43things. Milhares de page views/dia.

Mongrel é uma amostra de como Ruby pode ser rápido. Zed Shaw fez um excelente trabalho, por isso mesmo dedico um capítulo inteiro apenas à história do Mongrel. Colocar Lighty na sua frente configurado com proxy reverso ajuda ainda mais a servir o conteúdo estático. Configurar action cache nos controllers ajuda ainda mais. Existem diversas técnicas para tornar Rails tão ou mais rápido que seus concorrentes.

Exemplos:

• Railsexpress.org (este é o blog de Stefan Kaes, ele definitivamente entende de performance com Rails)
• Faster is Possible (o tutorial do site do Mongrel sobre configurar com Lighty)
• Finalmente, Apache 2.2+mod_proxy_balancer+Mongrel
• Blog do James Duncan Davidson (lembram dele? criador do Tomcat e do Ant? Tem excelentes artigos sobre deployment)
• Existem 3 tipos de técnicas de cache em Rails: page, action e fragment. A mais simples e com mais armadilhas é a page caching
• Esta apresentação é um pouco velha (algumas coisas mudaram), mas deve ajudar a dar uma visão do que Rails é capaz com caching.
• Improving Session Performance in Rails – Peter Krantz
• memcached Basics for Rails
• AssetPackager: Javascript and CSS asset compression

É bastante coisa mas pode ajudar. Muitos desses assuntos trato no meu livro. Desculpem ficar repetindo “livro”, “livro” o tempo todo (parece gravador quebrado …) mas é que realmente me preocupo muito com esse assunto. Performance exige tempo, paciência, técnica e não existe solução mágica. Mas nunca se esqueçam do que disse Donald Knuth: otimização prematura é a raíz de todo mal (ou pelo menos de boa parte dele).

Como recomenda David: hoje Rails é rápido o suficiente. Desenvolva sua aplicação prestando mais atenção à produtividade e qualidade. Depois meça! Como diz Stefan Kaes: tentar melhorar performance sem medições e perda de tempo é a mesma coisa. Descubra os gargalos. Tente usar alguns dos recursos de cache do Rails onde está realmente lento (não em tudo!). Otimize os gargalos de memória com memcached (é o que a 43things faz). Websites pequenos dificilmente sentirão problemas graves de performance com o básico: um aplicativo bem codificado e com deployment em Mongrel. Para os grandes sites, coloque Lighty ou Apache na frente, e siga essas recomendações.

Fica uma coisa meia complicada dizer que Ruby é lento mas as ferramentas feitas nele não. Talvez a gente possa simplificar dizendo como ter o melhor jeito de fazer as coisas, assim como em toda outra linguagem.

O Joel nem se deu ao luxo de usar Ruby de uma maneira mais adequada para fazer uma comparação (e pelo que eu me lembro nem é o primeiro flame dele sobre Ruby esse último), como ele mesmo disse no blog dele. Não sei para que diabos sai falando abobrinha de uma coisa que nem se propôs a conhecer direito se não tiver bytecode. Queimou o filme legal e já inventaram até um “ranking Spolsky” para pontuar posts idiotas, depois desses posts dele. :-)

Lógico que o core da linguagem tem muita coisa que precisa melhorar, que com certeza vai melhorar sim com o Rite, vindo aí os bytecodes, garbage collector híbrido (vamos ver se vem esse mesmo), etc.

Agora, acho muito importante o Ronie fazer os tutoriais: ficamos com uma referência local, rápida e certeira de uma coisa que estamos vendo rodar todo dia, a turma pode ver os resultados “na cara”, dar uma otimizada na “base” de seus projetos e depois ir aprendendo/discutindo/revisando técnicas de otimização do resto. Não seria otimização prematura, mas a mínima necessária depois de sair do Apache com CGI. :-)

E acharia até interessante fazer comparações com outras coisas que não fossem o Rails. Mas isso a gente pode fazer depois de matar a sede da turma com ele. :-)

Com toda certeza, tem razão. Aliás, material em português é imprescindível. Gostaria de convidar todos (todos mesmo, iniciantes e sêniors) a criar mais material. Não tem importância se já existe material semelhante, não tem importância se ficar incompleto. Lá fora existem dezenas de tutoriais no estilo “como começar com Rails” ou “como instalar o Mongrel”. A diversidade sempre traz detalhes que se complementam. Uma idéia que deixarei no ar (infelizmente não tenho muito tempo livre) é criar um Wiki, no formato do wiki.rubyonrails.org. Dessa forma todos que quiserem contribuir poderão escrever diretamente no site (Ronie?)

Acredito que o interesse em torno da tecnologia é o principal catalisador para suas melhorias. Lá fora surgiram muitos colaboradores com boas idéias de como melhorar Ruby. Veja _why (why, the lucky stiff) contribuindo com o esquema de sandboxes para a próxima versão do Ruby.

Discussões do tipo “Java VS Rails”, “.NET VS Rails” são importantes quando não se tornam simples flame wars. Por um lado as pessoas em dúvidas descobrem que Ruby tem toda a capacidade de ajudá-los. Por outro lado incentiva procurar soluções melhores. É o que leva tanta gente a criar plugins para Rails.

Ano passado na The Server Side.com tivemos artigos e discussões acaloradas como nesse link. Mas não somente “Java é melhor”. Muitos tentaram realizar análises, comparações. A net está lotada de comparações. Em 2005 aconteceram várias. O importante é conhecer todas as tecnologias possíveis. É a única maneira de ter consciência exata do que se está fazendo. Ninguém precisa “acreditar”, isso não é uma religião. Todos podemos buscar esse material todo, aprender e se convencer sozinhos.

Falando do Wiki: Na versão anterior do site tínhamos wiki, mas o uso era quase zero :) Daí não fizemos muita questão de colocar na versão nova.

Mas um lugar pra contribuições seria interessante sim!

Sobre performance: Ainda hoje devo liberar os gráficos de performance do CMS e do Fórum. Achei eles muito interessantes, acho que vai gerar uma bela discussão sobre caching.

Como prometido, os tempos dos dois sites estão nesse artigo aqui

Quem quiser brincar também, nós disponibilizamos os arquivos CSV com os dados. Comentários são benvindos nesse tópico mesmo. Se alguém quiser completar o artigo ou fazer outro com os dados, esteja a vontade.

Daqui duas semanas vamos ver tirar o gráfico de novo e ver se houve mesmo ganho ou se eu estava só sugestionado. :)

O pessoal do C costumava dizer que C++ era lerdinho por causa da orientação a objetos. De fato, C++ foi mais lerdo que C porque os compiladores eram muito novos.
Inconscientemente, o pessoal do C acabava usando uma espécie de orientação a objetos com struct (que é semelhante ao this).

Não sei até que ponto posso dizer isso, mas acho que desempenho você pode ganhar fazendo mudanças na sua arquitetura usando criatividade e ferramenta certa.

Você pode usar ruby bextensions, SWIG para conectar aplicações ‘legadas’ facilmente.