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!).
Ara Howard and Doug Fales has a great article on Linux Journal exploring Rails through a conversation. They talk about how thinks work building a small blog engine and touches on many of the Ruby facilities that Rails employ to do its magic. They also talk a bit about why some of the reactions to Rails have been so explosive and what kind of fears that are triggered when new tech hits the street. Great stuff.
The terror reign of intermittent MySQL errors has ended. We moved to a brand new dedicated server this morning thanks once again to the kind crew at TextDrive.
UPDATE: The wiki is offline for a bit today as the server will be reconfigured to allow larger memory allocations.
Rael Dornfest seems to be having a chocolate good time digging into the crunchy Rails. As the Chief Technology Officer at O’Reilly Media, he certainly has a good touch with the pulse of the industry and this is what he’s been seeing:
The chocolate in this equation is Ruby on Rails: a framework for building database-driven web applications. But far from being yet another web development framework, Rails is known for its small footprint, low barrier to entry, flexible-yet-powerful, “more joy and less code” approach to application building.
Indeed, we’ve been seeing interest in Ruby explode over the past few months: no doubt in large part due to the swift adoption (or at least tire-kicking) of Rails.
Ruby on Rails was off to a good start even before bringing Ajax on board; and it’s only gone from strength to strength since.
Thanks a bunch, Rael!
Evan Rabble is the lead developer on the forthcoming podcasting portal Odeo. He’s being working with Rails for some time now and has just done a write-up on how the productivity of the environment scales on a larger (than a todo example) project. Great perspectives. I especially like the one on the learning curve:
Another thing which i think is important when looking at web app frameworks is learning curve. I’ve had 4 other people pick up and contribute to the code base. Three of those people working remotely. They’ve all picked up and be able to understand the system quickly. The learning curve was very short and the code was generally readable.
This contrasts to my experience with zope, perl frameworks, and java. All three of those technologies had steep learning curves which required lots of face to face collaboration to bring people up to speed. With the exception of Florian, nobody had previous experience with rails or ruby beyond building a weekend example app and reading the tutorials.
Best of luck with the launch of Odeo!
It’s great to see so many Railers sign up with TextDrive. They’re a great host and I’m happy to be associated with them. But unfortunately, it appears that there’s some mismatch in expectations around what you get for a $12 plan.
What you do get is a slice of very reasonable specs on some great machines. What you don’t get is your personal system administrators. You should have your shit together before pushing it to TextDrive. Develop on your local machine, push to TextDrive when it works.
As explained, TextDrive is a shared host. That means its somewhat like a community park where everyone is responsible for cleaning up after their visit and behave with good manners. Think of your application as a park goer. Make sure its recently well-behaved by not taxing everyone else with needlessly sloppy queries or tough computations on every request.
Most importantly, though, is to be mindful about your support requests. As nice as it would be, the TextDrive system administrators can’t be part of your development effort debugging your application. They’re there in case the system as such is broke. So just like programmers should be careful before blaming the operating system for their program troubles, you should be careful before blaming TextDrive for yours.
TextDrive is a marvelous service. You get SSH, Rails, lighttpd, FastCGI, MySQL, SVN, PostgreSQL, and so much more for twelve dollars a month. 12. On top of that, they’re taking half of the profit from that to help Rails. I’d hate to see such a resource go away because unreasonable support requests and sloppy apps.
Let’s avoid The Tragedy of The Commons. Thanks.
Eric Hodel has released the Production Log Analyzer:
The Production Analyzer lets you find out which pages on your site are dragging you down. pl_analyze requires the use of SyslogLogger (included) because the default Logger doesn’t give any way to associate lines logged to a request.
Josh C from the Eggplant Coop sent me the funniest switcher quote I’ve seen in a while:
We compare moving to rails from our in-house perl web framework to the scene in “Clerks” where Randall goes to the good video store ;)
If you’re deep into all the RFCs on email, we’d like your help ensuring that the latest approach to encoding with Action Mailer is sound. We’re going for an approach where encoding to subjects and headers are only applied if necessary. Please do have a look at ticket #955.