papodenerd.net
puts “NOT just another development weblog”
5
Continuando a série de benchmarks começada ao comparar o Rails 2.1 com o Rails 2.2 em cima do Ruby 1.8, agora é a vez de comparar o JRuby e Ruby.
Se você não leu a explicação das diferenças do modelo de threading entre Ruby 1.8, Ruby 1.9 e JRuby, leia antes de prosseguir.
Estou rodando os testes no meu computador pessoal, que é um Pentium 4 3.0 HT, com 1Gb de memória rodando Ubuntu Linux. Já é um PC um tanto quanto ultrapassado, portanto o tempo de resposta acaba sendo um pouco alto, além de que ao mesmo tempo em que rodam os testes rodam também outros programas, como o Firefox por exemplo.
Vamos ao que interessa:
Ruby 1.8
$ ruby script/server -p 3001 -e production $ ab -n 50 -c 5 http://localhost:3000/ Concurrency Level: 5 Time taken for tests: 3.903964 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 573554 bytes HTML transferred: 547350 bytes Requests per second: 12.81 [#/sec] (mean) Time per request: 390.396 [ms] (mean) Time per request: 78.079 [ms] (mean, across all concurrent requests) Transfer rate: 143.44 [Kbytes/sec] received
JRuby 1.1.4
$ jruby -J-Djruby.objectspace.enabled=false -J-Xmn128m -J-Xms512m -J-Xmx512m -J-server -J-Djruby.thread.pooling=true script/server -e production $ ab -n 50 -c 5 http://localhost:3000/ Concurrency Level: 5 Time taken for tests: 7.976448 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 573600 bytes HTML transferred: 547350 bytes Requests per second: 6.27 [#/sec] (mean) Time per request: 797.645 [ms] (mean) Time per request: 159.529 [ms] (mean, across all concurrent requests) Transfer rate: 70.21 [Kbytes/sec] received
Mesmo utilizando todas as flags de performance tunning da wiki do JRuby, ele ainda se mostrou mais lento. Isso significa que o JRuby não vai tirar proveito do threadsafeting do Rails 2.2? Não!
Pelo que eu entendi pesquisando brevemente, ainda é preciso fazer alterações no código do JRuby pra que ele ofereça a melhor performance possível. Mesmo a última barreira para que o Rails possa ser executado em modo multi-threaded tenha sido removida, ainda é preciso implementar essa função no core do JRuby. Me corrijam se eu estiver errado.
Tempo de carga de uma única requisição no JRuby:
Processing IndexController#index (for 127.0.0.1 at 2008-10-30 18:44:58) [GET] Completed in 186ms (View: 116, DB: 7) | 200 OK [http://localhost/]
…e no Ruby:
Processing IndexController#index (for 127.0.0.1 at 2008-10-30 18:45:13) [GET] Completed in 131ms (View: 60, DB: 20) | 200 OK [http://localhost/]
O Ruby é 2x mais rápido que o JRuby ao renderizar a view, mas quase 3x mais lento em consultas ao banco.
Alguém já brincou com o JRuby e Rails 2.2? Obteve resultados melhores? Comentem.
Hoje resolvi testar a minha aplicação de várias formas, pra ver se a nova versão do Rails traria algum benefício de fato para mim.
Primeiro rodei o Apache Benchmark na aplicação do jeito que ela estava, como Rails 2.1.1:
$ ab -n 50 -c 5 http://localhost:3000/ Concurrency Level: 5 Time taken for tests: 39.938685 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 1036850 bytes HTML transferred: 1010700 bytes Requests per second: 1.25 [#/sec] (mean) Time per request: 3993.869 [ms] (mean) Time per request: 798.774 [ms] (mean, across all concurrent requests) Transfer rate: 25.34 [Kbytes/sec] received
Hummm.. lento.. muito lento. Já estava preocupado com a hora de colocar isso em produção.
Atualizando o Rails para a versão 2.2 e rodando o benchmark:
$ ab -n 50 -c 5 http://localhost:3000/ Concurrency Level: 5 Time taken for tests: 32.228686 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 590650 bytes HTML transferred: 564400 bytes Requests per second: 1.55 [#/sec] (mean) Time per request: 3222.869 [ms] (mean) Time per request: 644.574 [ms] (mean, across all concurrent requests) Transfer rate: 17.87 [Kbytes/sec] received
What?? Cadê a melhora de performance? Rails não é Threadsafe agora?
É! Mas você tem que habilitar o recurso nas configurações pequeno Padawan:
No seu arquivo config/development.rb adicione no final:
config.threadsafe!Rodando o Benchmark:
$ ab -n 50 -c 5 http://localhost:3000/ Concurrency Level: 5 Time taken for tests: 6.807438 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 590620 bytes HTML transferred: 564400 bytes Requests per second: 7.34 [#/sec] (mean) Time per request: 680.744 [ms] (mean) Time per request: 136.149 [ms] (mean, across all concurrent requests) Transfer rate: 84.61 [Kbytes/sec] received
Muito melhor não?! Uma melhora de quase 500%! Mas e se rodassemos em modo de produção?
$ ab -n 50 -c 5 http://localhost:3000/ Concurrency Level: 5 Time taken for tests: 3.693437 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 573555 bytes HTML transferred: 547350 bytes Requests per second: 13.54 [#/sec] (mean) Time per request: 369.344 [ms] (mean) Time per request: 73.869 [ms] (mean, across all concurrent requests) Transfer rate: 151.62 [Kbytes/sec] received
Impressionado pequeno Padawan? Cuidado! Nada disso aqui significa que sua aplicação vai ficar tão melhor quanto a minha somente com a nova versão do Rails. A aplicação em questão aqui envolve muitos cálculos complexos, e por isso tira vantagem do threading.
Tentei fazer alguns testes com o mysqlplus, driver de mysql pra ruby que promete acesso assíncrono ao banco de dados. O tutorial que eu segui simplesmente não funcionou no meu ambiente. Li em algum dos posts que pesquisei que eles estavam concentrando esforços pra fazer funcionar com o Rails 2.2 e corrigir alguns bugs.
Rails escala? Pra minha aplicação sim. E pra sua?
Back to top
RSS Feed
