Justin Gehtland is back with numbers to back up his original claim that “Rails is actually faster” for his application than the Java/Spring/Hibernate/JSTL stack powered version was. Through various benchmarks, he has found Rails to be roughly 15-30% faster than the old Java version. Interestingly enough, it seemed that Rails was especially better performing on deeper domain features:

What I found was that, the less complex the feature, the faster the Java app served it relative to the Rails app. The more complex the feature, the slower the Java app served it relative to the Rails app.

Looking at pages that are a good fit for caching, the difference is a lot more startling. While Justin admits that there was probably a lot more work with tuning and tweaking that could be done on the Java versions (where page caching in Rails is triggered by 1 line of code), his tests shows the Rails version to perform 1,754-1,785 requests/second vs the 80/88 requests/second on the Java side.

The blistering performance is naturally due to the way that Rails steps out of the way for page caching and lets lighttpd serve the caches straight from the static cached files. So while the difference is 20:1, it’s not that interesting a comparison. Except for the point that this type of page caching is integrated in the Rails framework and used by default. So it requires no effort to get this type of performance.

But even though Justin now has the numbers to back up his claim about his particular application, such numbers are not in generally all that interesting. I concur with Justin that the interesting conclusion is that Rails isn’t naturally dog slow because its in Ruby and a Java/Spring/Hibernate/JSTL-stack app not automatically blazing fast because its in Java:

To me, the eye-opening revelation isn’t “Rails is faster than Java/Spring/Hibernate”. It’s “Rails can be very fast”. I think that there is a lot to be said for Rails, and it deserves much of the press it is getting.

Size of the application
Just as extract general lessons about performance from particular applications, so is it hard to compare the size and complexity of two solutions implementing the same application. So measurements such as KLOC are hardly the be all, end all. They’re merely indicators.

But as such indicators go, Justin serves a rather nice one with the comparison on his application. The Rails application was done with 1,277 lines of code and configuration while the Java-stack application required 4,454 lines. About a factor of 3,5×. And here comes the kicker, the Rails application includes a month’s worth of new features added over the abandoned Java version.

So what does all this mean? Justin concludes…

I think that the application I’m working on is perfectly suited for Rails and Rails is perfectly suited for it. I think that I have had more fun working on the Rails app than the Java version. However, I think that the Java version is just as capable, and could be just as performant, as the Rails app.

I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I’ve discovered Rails. On the other hand, I am going to spend more of my time trying to find projects that I can use Rails on.

Justin Gehtland is the co-author of Spring: A Developer’s Notebook due out this month (congratulations!).