Ruby On Rails Showdown with Java Spring/Hibernate

Paradox writes "Java developer Justin Gehtland recently tried re-implementing one of his web applications in Ruby on Rails instead of his normal Java Spring/Hibernate setup. His analysis of overall performance and application size was startling, to say the least. The Java app's configuration alone was nearly the size of the entire Rails codebase, and Rails application was significantly (15%-30%) faster! At the same time, the Ruby community is abuzz because Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"

Comments

Article Text

[Anonymous Coward]

Article text in full, copied directly from Justin's blog:

So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.

The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.

The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.

I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).

Now, for the comparisons:

Time to Implement
I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.

Lines of Code
This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*

Re:Faster?

[ajs]

When we say "optimized bytecode compiler" these days, we generally mean that it does JIT. I know, I know, it's bad use of the terminology, but generally that's what people mean.

Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.

At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)

Re:Ruby is a toy

[Paradox]

There is no serious caching

Incorrect. In fact, RoR's caching complete destroys Java's caching in Justin's comparison. You can read about Rails' caching here.

No serrious transation capabilities

Obvious jokes about your spelling aside, Ruby provides these already. Rails does not need to provide them.

or messaging mechanisms.

This complaint is flawed. However, Rails can accomplish what you're asking for if you want to. It's just that, assuming I understand what you're parroting, it's a very bad idea to do it.

hype and buzz.

Only if you don't bother to find out the truth.

This is a flawed recollection.

[Paradox]

There was a brief example of this on ONE of the wiki-based tutorials in which the person posting the tutorial didn't use Rails's built in SQL search features or safety features. Because of this, there was an SQL injection hole. It was promptly corrected.

No amount of safety can make up for novice mistakes. Rails provides everything you need to make secure webapps, and it lets you do it painlessly.

Re:any comparison like this...

[aziegler]

Full disclosure: I don't particularly like the Rails way of doing things with databases, because it bases its data interaction semantics as if MySQL were a good (rather than an "easy") database.

That said:

1. Ruby has SOAP capabilities and it's built into the core of Ruby (SOAP4R). Just because someone has not yet seen fit to mix ROR and SOAP doesn't mean it can't be done.
2. Ruby can do RMI/remote invocations through DRb or other mechanisms. Of course it can't do Java RMI without a JNI connector, but those JNI connectors are available -- and there's even a nascent JWDP connector for additional interaction with Java.
3. There is some queueing technology available for Ruby. I haven't had a need for it, but it's available. Or buildable.
4. ROR prefers you to design the database from scratch, but it certainly doesn't prevent you from using an existing database and doing a bit of extra coding to make it Just Work. The good thing about ROR is that it uses sane defaults to make the common brain-dead simple. You can manually implement a mapping. There might be room for an easier mapping mechanism in cases like this (rather than defining self.table_name and self.primary_key), but as ROR is still an evolving framework, that's not a big deal.

The assessment on the Rails blog is, I think better. The numbers are impressive but meaningless -- there are tweaks that can be done in any case. The real point is that this shows that Ruby Isn't Slow and that Rails (or any other application environment) can be used in a production environment.

Spoke to Justin about this...

[scottsevertson]

At the Milwaukee No Fluff Just Stuff conference, I was invovled in a lunchtime conversation with Justin and [Pragmatic] Dave Thomas about this subject, just days after Justin completed the Ruby code.

The concensus at that point: it probably wasn't a difference in *execution* speed, but smarter data retreval strategies used by Rails persistance layer. While Hibernate has excellent support for lazy loading, both developers thought that Rails was being *lazier*.

Justin's new numbers also point to faster caching in RoR's persistance layer: while both applications performed about equally without pre-cached data, RoR performed 20x better than the Java stack with cached data [both versions using similar caching strategies].

As for those questioning Justin's java skills: he's one of the best programmer's I've had the privilege to know, one of the best speaker's I've listend to, and is freaking hilarious to boot. He's the co-author of O'Reily's Better, Faster, Lighter Java, and he regularly speaks on advanced Hibernate, Spring, and a bunch of other Java topics.

He also points out a *significant* decrease in Lines of Code[Java:3293 RoR:1164] and Lines of Configuration [Java:1161 RoR:113]. While not an accurate gauge of effort, it is another point in Ruby's favor.

Last point for Ruby: Every single *top notch* Java programmer I know is at least playing with Ruby and RoR, with a large percentage [>50%] transitioning to Ruby as a first choice for new project work.

Don't call it a toy until you've played with it. There's some pretty convincing evidence that Ruby/RoR can beat Java for development effort, and now we're seeing it can beat it for performance, too.