Comments on: Rails and Grails performance compared http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/ Grails developer/consultant Mon, 08 Mar 2010 21:39:29 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Marc Palmer http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-105793 Marc Palmer Sat, 06 Dec 2008 19:16:03 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-105793 Adrian - this was a long time ago - 1.5years. Can't remember sorry Adrian – this was a long time ago – 1.5years. Can’t remember sorry

]]> By: Adrian http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-105788 Adrian Sat, 06 Dec 2008 17:33:15 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-105788 Can you confirm the JVM options you used when starting tomcat - particularly the Xmx? Can you confirm the JVM options you used when starting tomcat – particularly the Xmx?

]]> By: Erik van Oosten http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-18961 Erik van Oosten Fri, 30 Mar 2007 13:42:22 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-18961 And if I may add, please make sure you use Ruby 1.8.5. It is considerably faster then earlier versions. And if I may add, please make sure you use Ruby 1.8.5. It is considerably faster then earlier versions.

]]> By: Erik van Oosten http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-18959 Erik van Oosten Fri, 30 Mar 2007 13:37:30 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-18959 Thanks for these nicely done measurements. Could you please, for the next round, repeat the Rails tests with erubis (http://www.kuwata-lab.com/erubis/). Erubis replaces the default erb to do the rhtml parsing and rendering. Instructions. First install erubis: # gem install erubis Then add the following line to "config/environment/production.rb": require "erubis" Good luck! Thanks for these nicely done measurements.

Could you please, for the next round, repeat the Rails tests with erubis (http://www.kuwata-lab.com/erubis/). Erubis replaces the default erb to do the rhtml parsing and rendering.

Instructions. First install erubis:
# gem install erubis

Then add the following line to “config/environment/production.rb”:
require “erubis”

Good luck!

]]> By: Marc Palmer http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-18143 Marc Palmer Tue, 27 Mar 2007 12:00:52 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-18143 Stephan - this is not quite correct. C vs. Java is an oversimplification. If anything it is testing the implementation of the languages (Ruby in C, Groovy in Java), not the underlying languages. You can't compare the max speed of two car engines unless both cars have identical weight, aerodynamics etc and Groovy and Ruby are very different implementations, so your comparison is meaningless. This is measuring what happens when you run the full application stack, that's all. Stephan – this is not quite correct. C vs. Java is an oversimplification. If anything it is testing the implementation of the languages (Ruby in C, Groovy in Java), not the underlying languages.

You can’t compare the max speed of two car engines unless both cars have identical weight, aerodynamics etc and Groovy and Ruby are very different implementations, so your comparison is meaningless.

This is measuring what happens when you run the full application stack, that’s all.

]]> By: Stephan http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-17893 Stephan Mon, 26 Mar 2007 15:49:46 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-17893 Ravi, I thought most Ruby code is C? (Not the Rails code). Which means this compars a.) DB I/O performance b.) C versus Java Ravi,

I thought most Ruby code is C? (Not the Rails code). Which means this compars a.) DB I/O performance b.) C versus Java

]]> By: Ravi http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-16881 Ravi Fri, 23 Mar 2007 23:49:36 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-16881 I'm not surprised that Grails is faster on most tests, even after you reran your tests using a cluster of mongrels. You're still really comparing apples to oranges-- Java runs as jit'ed bytecode and Ruby is interpreted directly. Bottom line, in my tests Java can be over an order of magnitude faster in the general case. I think its a credit to Rails that it actually won even one of the benchmarks! ;-) Just goes to show that at the end of the day most db driven web apps are io bound. I’m not surprised that Grails is faster on most tests, even after you reran your tests using a cluster of mongrels. You’re still really comparing apples to oranges– Java runs as jit’ed bytecode and Ruby is interpreted directly. Bottom line, in my tests Java can be over an order of magnitude faster in the general case. I think its a credit to Rails that it actually won even one of the benchmarks! ;-) Just goes to show that at the end of the day most db driven web apps are io bound.

]]> By: John Wells http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-16852 John Wells Fri, 23 Mar 2007 20:46:34 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-16852 Marc, Well, I'm that user who's doing the testing. And I need to clarify. Rails doesn't get worse when going from 1 to 10 mongrels...it actually gets much better. However, going from 10 to 20 had a slightly negative impact: http://thoughtmining.blogspot.com/2007/03/grails-versus-rails-comparison.html Marc,

Well, I’m that user who’s doing the testing. And I need to clarify. Rails doesn’t get worse when going from 1 to 10 mongrels…it actually gets much better. However, going from 10 to 20 had a slightly negative impact:

http://thoughtmining.blogspot.com/2007/03/grails-versus-rails-comparison.html

]]> By: Marc Palmer http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-16844 Marc Palmer Fri, 23 Mar 2007 20:15:52 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-16844 These tests are being done by a Rails/Grails user. So far, Rails gets worse with more mongrels, but they are still looking into it. Threading boosts concurrency, not performance. A single Rails mongrel running at full pelt and with an unloaded (single DB sessions at a time) MySQL is likely to be faster than any threaded solution, as far as I can see currently. No timeslicing, bottom line. Multi-threading slows things down if anything, but improves the concurrency under load. We did not detail # concurrent sessions per second so this aspect of performance, is arguably not relevant. These tests are being done by a Rails/Grails user. So far, Rails gets worse with more mongrels, but they are still looking into it.

Threading boosts concurrency, not performance. A single Rails mongrel running at full pelt and with an unloaded (single DB sessions at a time) MySQL is likely to be faster than any threaded solution, as far as I can see currently. No timeslicing, bottom line. Multi-threading slows things down if anything, but improves the concurrency under load.

We did not detail # concurrent sessions per second so this aspect of performance, is arguably not relevant.

]]> By: Paul Barry http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/comment-page-1/#comment-16794 Paul Barry Fri, 23 Mar 2007 16:16:18 +0000 http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/#comment-16794 A rails application is not threaded like a Java app. What this means is that when you only have 1 mongrel process, all requests must be processed serially. This is not true for 1 tomcat instance. Since tomcat is a java app, it is threaded and process multiple requests at once, when gives it better performance under a concurrent load. The way you handle more concurrent requests with a Rails app is to run multiple mongrel instances (on the same server, a different port for each) using mongrel_cluster[1]. Then you use something like Apache 2.2's mod_proxy_balancer to load balance the requests across the multiple mongrel instances. It would be interesting to see these tests run again with mongrel_cluster running 2, 4, 6, 8, et.c instances to see what impact that would have. for this kind of test, I would guess that it actually wouldn't be a tremendous boost, because each requests should be very fast. But when testing requests that can take longer than a few milliseconds, especially where uploading or downloading of large amount of data is concerned, the performance difference would probably be huge with using multiple mongrel instances. http://mongrel.rubyforge.org/docs/mongrel_cluster.html A rails application is not threaded like a Java app. What this means is that when you only have 1 mongrel process, all requests must be processed serially. This is not true for 1 tomcat instance. Since tomcat is a java app, it is threaded and process multiple requests at once, when gives it better performance under a concurrent load.

The way you handle more concurrent requests with a Rails app is to run multiple mongrel instances (on the same server, a different port for each) using mongrel_cluster[1]. Then you use something like Apache 2.2’s mod_proxy_balancer to load balance the requests across the multiple mongrel instances.

It would be interesting to see these tests run again with mongrel_cluster running 2, 4, 6, 8, et.c instances to see what impact that would have. for this kind of test, I would guess that it actually wouldn’t be a tremendous boost, because each requests should be very fast. But when testing requests that can take longer than a few milliseconds, especially where uploading or downloading of large amount of data is concerned, the performance difference would probably be huge with using multiple mongrel instances.

http://mongrel.rubyforge.org/docs/mongrel_cluster.html

]]>