MouseOver Studio

MouseOver Studio header image 2

Ruby vs Java e como a tartaruga venceu novamente a lebre

March 8th, 2009 por Diego Carrion · 18 comentários

Trabalhei dois sprints de duas semanas num projeto programado em Java, junto a dois desenvolvedores mais. Antes de começar os sprints sugeri utilizar a arquitetura Ruby on Rails mas o cliente alegou que a performance era um fator importantíssimo.

A escolha das ferramentas Java foi livre pelo que felizmente conseguimos pegar o que tem de melhor no mercado: VRaptor e Hibernate. Essas duas ferramentas nos ajudaram a acelerar bastante o tempo de desenvolvimento. Não esquecer que o projeto foi feito em 4 semanas, por tres desenvolvedores (guardar esses valores para mais tarde).

Somente como momento propaganda, a versão utilizada do VRaptor foi a VRaptor Sexy URLS.

Uma vez terminado o ultimo sprint, dediquei um tempo à realizar uns testes de stress enquanto analisava tudo com o JProfiler. A aplicação não possuía nenhum memory leak ou coisa similar, mas mesmo assim algumas alterações melhoraram a performance.

Foi realizado um novo deploy da aplicação no ambiente de produção e o cliente gostou do produto, pelo que foi mantido assim.

Uma semana depois aproveitei um tempo livre que teve para desenvolver a aplicação novamente, dessa vez utilizando Rails. Lembram quanto tempo demoro utilizando os frameworks Java? Utilizando Rails + plugins consegui desenvolver a mesma aplicação em somente duas horas!

Mas isso não é tudo, queria comparar a performance da aplicação feita em Rails com a feita em Java. Eu tinha um script que simulava diversos usuários utilizando a aplicação, o mesmo script que utilizei para realizar o profiling da aplicação Java, pelo que aproveitei ele para medir o tempo de execução frente as duas aplicações, uma rodando sobre o Glassfish e a outra sobre o Passenger.

Para surpresa de muitos, a aplicação Rails rodando sobre Passenger respondeu bem mais rápido às diferentes requisições que a aplicação Java (32 vs 60 segundos)! Isso pode surpreender a muitos, mas não é a primeira vez que algo assim acontece. No Falando em Java 2008 o Fabio Kung mencionou que parte do Guj foi rescrito em Rails, ao mesmo tempo que a performance melhorou notavelmente. Mas sem lugar a dúvida, o exemplo maior de uma aplicação Java que foi rescrita em Rails sem perder a performance é o caso do YellowPages.com, aplicação com nada menos que 150 mil requisições por segundo. Mas detalhes sobre a rescrita podem ser vistos aqui.

Para ir terminando a historia, eu consegui gastar um bom tempo tunando a JVM e o servidor Glassfish, mas somente por diversão, como desafio, porque para o cliente não mudou nada! Não mudou nada porque a diferença somente pode ser percebida com MUITOS usuários, realizando MUITAS requisições, bem mais, mas bem mais mesmo das que a aplicação pretendia receber.

Se você é uma das pessoas responsáveis por escolher uma tecnologia num projeto e você pretende deixar de escolher Rails porque alega alguma coisa relacionada a performance, então você deve pensar no assunto uma vez mais.

Caso você seja uma rara exceção, vamos ser sinceros, tua aplicação bem desenvolvida nunca vai precisar da JVM e do servidor tunados ao máximo, nem sequer tunados ao ponto no qual uma aplicação em Rails não consiga chegar. Isso considerando que a aplicação vai estar bem desenvolvida, mas provavelmente ela não vai estar. Na maioria dos casos as aplicações Java tem problemas de performance a nível de código. Os desenvolvedores escrevem tanto mas tanto código que terminam deixando brechas para poder acontecer um processamento elevado ou ate alguns memory leaks.

Quanto menos código você escrever e quanto mais simples ele for, menores vão ser as possibilidades de um problema acontecer, e isso é algo que ajuda as aplicações feitas em Rails a terem uma boa performance com esforço mínimo, as chances de errar são muito menores.

Tags: java · performance · ruby

18 respostas ate agora ↓

  • 1 Jeveaux // Mar 8, 2009 at 8:48 pm

    Muito bom o relato, Diego.

    O que eu sempre digo nos meus clientes é que a definição de frameworks e principalmente da linguagem é o que menos vai interferir na performance, ao menos inicialmente a arquitetura deverá ser a grande preocupação caso a performance for um fator importante. Então tento sempre deixar a decisão de linguagens e tecnologias envolvidas para quando o projeto for iniciado e deixar o time tomar esta decisão.

    É muito difícil você encontrar uma situação onde a linguagem em si é o gargalo, normalmente isso só poderá ser constato, de fato, quando você tiver a melhor arquitetura possível, melhor código possível, tuning de ambiente e demais melhorias possíveis e tiver mais o que fazer, nesses casos a substituição de tecnologia/linguagem acaba sendo a única alternativa.

    Só achei meio extremista a comparação de tempo e esforço. Quatro semanas com três desenvolvedores Java contra duas horas com um desenvolvedor rails. Você deve concordar que nessas quatro semanas devem ter havido sprint planning que não houveram na versão rails, reuniões com o cliente, reviews e retrospectivas, definição de interface e usabilidade da aplicação e até mesmo a criação da interface em si. Não duvido que você tenha feito a aplicação em rails em 2 horas, de forma alguma, apenas acho que os itens anteriores ou foram reaproveitados (nesse caso deveriam entrar para ‘contagem de horas’) ou foram ignorados.

  • 2 Abraão Coelho // Mar 8, 2009 at 10:50 pm

    Bom, talvez eu concorde com a parte do comentário do Jeveaux sobre a comparação de horas, afinal, vc já tinha a idéia completa do produto final quando começou… Mas sim, teria levado menos tempo mesmo assim hehehe

    Achei muito bacana esse tipo de comparativo, serve para vermos que é possível sim fazermos apps em Rails que correspondem à performance esperada.

    Pra ficar mais legal ainda, ia ser bacana deixar dados estatísticos por aí… Eu não costumo olhar pra eles não, mas se eu mostrar o post pra um colega meu ele vai ficar dizendo que é tudo conversa hehehe

  • 3 Diego Carrion // Mar 9, 2009 at 1:12 pm

    É verdade Jeveaux e Abraão que a comparação não é completamente justa. Nos dois sprints tiverom mesmo aqueles reviews, planejamentos e outras reuniões que influenciaram no tempo.

    Mas não só isso, antes de começar a aplicação em Rails, eu fiquei pensando no dia anterior sobre quais plugins ia utilizar e como ia fazer tudo. Quando cheguei no trabalho, fiz logoff em tudo (twitter, gmail, msn, etc) e fiquei programando essas duas horas ja com tudo na cabeça, contra o relógio :P

    Mantive os tempos para chamar um pouco atenção e porque apesar de tudo, é um tempo possível :)

  • 4 Leandro Silva // Mar 9, 2009 at 1:33 pm

    Fala Diego!

    Achei legal o comparativo e o artigo, cara…

    Agora, só um detalhe, pra sacar melhor: Que tipo de aplicativo você fez? Descreva um pouco, pra gente ter uma idéia do tamanho do esforço. (Não precisa falar o nome do cliente, nada disso, só o tipo mesmo.)

    Abraço!

  • 5 Hugo Baraúna // Mar 9, 2009 at 1:33 pm

    Ótimo post! Vai ficar guardado como referência para comparação de aplicativos em Java X aplitcativos em Rails. =)

  • 6 miguel baldi // Mar 9, 2009 at 1:41 pm

    Diego, ficou muito interessante este post. Seria legal se você colocasse as evidencias do profiling (eu acredito em você, é só para enriquecer o post) e o setup de plugins que você utilizou na versão rails. Gostaria de usar estas informações para mostrar o Rails para alguns java-boys xiitas, hehe. Muito show, abraço.

  • 7 George Guimarães // Mar 9, 2009 at 1:55 pm

    Lindo post!…
    Ótimo exemplo!

  • 8 Sandro Santos // Mar 9, 2009 at 2:34 pm

    Diego,

    Ótimo arquivo, mas teria como você mostrar o caminho das pedras, tipo quais frameworks você usou e tudo mais?

    []´s

  • 9 Douglas Campos // Mar 9, 2009 at 6:10 pm

    Muito legal a comparação

    pq vc não testa com o JRuby pra gente ter uma idéia?

  • 10 Diego Carrion // Mar 14, 2009 at 2:30 pm

    Antes de publicar o post, eu conversei com meu cliente sobre o mesmo e a única condição que me deram para poder realizar tudo “politicamente” :P era que não desse detalhes do cliente final, de modo que ele não chegue a saber que pudo ter gastado bem menos pelo mesmo produto.

    O que eu posso dizer da aplicação que ela tem muitos recursos de colaboração e também tem uma parte altamente baseada em serviços.

    Vou tentar pegar um tempinho nessa semana e realizar novamente o profiling para tomar uns screenshots. Não vou poder mostrar tudo porque em algumas partes do JProfiler aparece o nome dos pacotes mas algo vai dar para mostrar.

    Ai também aproveito e roda a aplicação Rails com JRuby, que era algo que queria ter feito no começo mas como tava com pouco tempo e pressa, terminei esquecendo :P

    E obrigado pelos comentários :)

  • 11 Alexandre // Mar 15, 2009 at 6:33 pm

    Ótimo post Diego, parabéns kra!

    Acho que em questão de detalhes e tudo mais até é importante, mas além disso esse post mostra algumas coisas como http://blog.fragmental.com.br/2008/12/09/nao-vai-subir-ninguem/

    Uma grande vantagem é não ter que ficar perdendo tempo com arquitetura ficar justificando horas com configurações de framework e sim dedicar-se ao negócio e pronto.

  • 12 Tiago Albineli Motta // Mar 18, 2009 at 2:23 pm

    Sem duvida, depois de começar a desenvolver em Ruby e Rails, percebe-se a sensacional melhoria de produtividade.

  • 13 Daniel Cukier // Mar 30, 2009 at 7:27 pm

    Você levou 2 horas em Rails e 2 semanas em Java, é isso? Temos que levar em conta que, da segunda vez que você fez a aplicação, você já tinha um conhecimento prévio. Com certeza se você tivesse que fazer a mesma aplicação do zero, em Java, levaria muito menos tempo. Seria legal avaliar qual é o ganho REAL com o Rails. Outra coisa, esse ganho de produtividade pode variar, de acordo com o tipo de aplicação que você fez. Se sua aplicação em Java era um monte de telas tipo CRUD, óbvio que você faria tudo em 5 minutos usando scaffold.

  • 14 Paulo // May 6, 2009 at 4:05 pm

    Olá, sou novato em web e gostaria de saber como funciona esses testes de estresse?
    Já programei alguma coisa em rails, mas como testar o estresse?

    Valeu!

  • 15 Diego Carrion // May 6, 2009 at 4:15 pm

    Oi Paulo, você pode utilizar alguma ferramenta como o JMeter mas no mundo Ruby não acho muito necessário, acostumo criar scripts que simulam diversas requisições em simultâneo.

  • 16 Crud // Aug 30, 2009 at 2:59 pm

    Pegou um crudzão e fez no braço em java sem usar nenhum tip de scaffold e depois gerou tudo em rails…

    se pesquisar vai encontrar scaffold pra varias linguagens.

  • 17 Javier Gutierrez // Feb 1, 2011 at 1:49 pm

    Hola, justo ahora estoy por elegir la plataforma que propondre. Tu historia me ha generado mucho interes por Rails

  • 18 Crud // Feb 16, 2012 at 11:35 pm

    Se o Rails fosse feito só de scaffold…

Deixar um comentário