Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Rails is 8 times slower than Spring+Hibernate

Might as well start off this week by getting people's blood boiling. ;-) According to a comment on Dion's blog:

Having done extensive performance (scalability means different things to different people) testing on both Rails and a comparable Spring/Hibernate/JSP2 webapp (no one seems have have done any sort of benchmarking on Rails, or they simply don't care, I don't really know, but since benchmarking is what I do... :-)) I can say that Apache2/FastCGI/Rails is about... 8x slower than the comparable Tomcat/Spring/Hibernate/JSP2 solution. And that is with caching turned on in Rails (using Rails 0.9.5...)

Quite frankly, 62 req/s on a Dual Opteron with 4GB of RAM rendering a simple view with no DB access is too... damn slow.

Personally, I still think Rails looks like a great (and easy) way to develop webapps. I just wonder if there's some truth to the "can't scale" argument. I guess the best way to find out is for me to develop an application like AppFuse with Rails, and then hammer it (and AppFuse) with JMeter to see what kind of results I get.

On a sidenote, I wonder when Rails will hit the illustrious version 1.0? They released 0.1 last week - which is a bad version number for marketing. If it's as mature as folks claim, why not make the next release 1.0? That version number alone will likely allow developers to use it more in big companies.

Posted in Java at Feb 28 2005, 06:25:27 AM MST 15 Comments
Comments:

Actually, they released 0.10.0, that is, zero point ten. The same versioning scheme is used in Apache, for example (admittedly it's quite confusing, on a quick glance it 0.9 definitely seems newer than 0.10...) I guess Rails is very mature already, but there is a roadmap of the features that need to be finished before they call it 1.0.

Posted by Jari Aarniala on February 28, 2005 at 08:20 AM MST #

If you stick to the shared-nothing architecture popularised by PHP Rails will scale just fine - that's how Flickr (PHP) and LiveJournal (Perl) manage to scale up to cope with millions of users. The relatively poor performance of Ruby will make scaling up more expensive than if you were using a different technology though as each additional load balanced server will deal with less traffic than it would have under another technology. The question then becomes which is more expensive: paying for more developer time needed with other platforms, or paying for more server hardware should you need to scale. So my opinion is that Rails can scale just fine, but at a higher cost than better performing technologies. Of course, the vast majority of applications won't ever need to scale beyond one reasonably well specced server.

Posted by Simon Willison on February 28, 2005 at 08:34 AM MST #

The real question is: Is Rails *fast enough* for its target application? Probably a yes (for Intranet applications). In addition, Jamis Buck (at the UJUG presentation) did do a credible job answering the performance/scalability question (for Internet applications). Remember the C++ vs. Java speed debate. Finally, I'll be interested to see where Trails applications come up on the complexity-of-development curve and on the performance curve.

Posted by Howard Lewis Ship on February 28, 2005 at 08:34 AM MST #

Another thought: I'd imagine Spring+Hibernate is 8 times slower than the same application written in hand-optimised assembler. That doesn't mean optimised assembler is a better option!

Posted by Simon Willison on February 28, 2005 at 08:36 AM MST #

I wouldn't do a Trails performance benchmark just yet. We're at version 0.51, and not even alpha quality yet. Need to do lots of caching of descriptor type info before performance will be worth measuring. But incidentally, I agree with Howard about Rails. The important question is not how fast is, but is it fast enough for what you want to do with it. Developer productivity is usualy worth more $ than raw performance, or else we'd all be coding assembler. Still interesting to measure such things, though.

Posted by Chris Nelson on February 28, 2005 at 09:13 AM MST #

While I would welcome some well constructed benchmarks to compare performance, its unfortunate that this one flawed report is getting cited repeatedly. The original poster had been running tests that compared the Ruby wiki software Instiki, with some corresponding python framework and then used that to draw conclusions about rails. The problem is that Instiki is *not* a Rails app. While is does use an early prerelease version of ActionPack (a component of Rails), its is, none the less, *not* a Rails app and the conclusions drawn are therefore invalid.

Posted by Curt Hibbs on February 28, 2005 at 11:43 AM MST #

Hi. What do sites like LiveJournal and Flickr do for the DB? Are they running a single DB instance or do they cluster or do they use some sort of routing, anyone know?

Posted by Frank on February 28, 2005 at 01:00 PM MST #

Hey Matt, we're targeting Early april for 1.0 and as Jari mentioned, it's 0.10 we just released. I agree with curt, this 'benchmark' is meaningless really. How well tuned were both applications, how well optimised was the database? What on earth does 'two comparable webapps' mean anyway!? After all, Roller is 874x slower than wordpress ... ;) Cheers Koz PS. Frank, check http://www.danga.com/words/ for presentations on Live Journal's architecture

Posted by Michael Koziarski on February 28, 2005 at 02:16 PM MST #

Be careful not to confuse performance with scalability. Scalability means that the system can be made to handle lots of users, generally through adding hardware. Usually scalability is driven by architecture decisions (e.g., how much information is shared); from my experience with Rails and from my usage of several commercial rails-based applications with thousands of users (Basecamp, 43 Things, tadalist), Rails seems to scale just fine.

Posted by Mark Muday on February 28, 2005 at 03:11 PM MST #

This is going to be a bit repetitive to what was already said, but that won't stop me. I am by no means a Rails enthusiast, but.... Hardware is a lot cheaper than developers. If it is 8 times slower, but 10 times more productive than it is a good bet for a lot of applications. (Most apps are not eBay anyway.) Remember when Visual Basic was popular? VB was 20 times slower than C++ and Delphi, but in 1996 it was used more than the two combined. BTW On a side note, speed does not equal scalability.

Posted by Rick Hightower on March 01, 2005 at 06:37 PM MST #

Hi there,

I'm the original poster on Dion's blog.

By "comparable web app" I mean, I wrote the same app (with the exact same functionality) in Rails and Spring+Hibernate (I did use AppFuse to get this up and running quickly so I could do the testing... :-))

No, I didn't use Instiki (I don't know where that idea comes from) and I did make the disclaimer about scalability != performance, and I did mention, in the post on Dion's blog, that Rails was more productive.

I was far more productive in writing the Rails app. It took me all of one night to do it.

When I say 8x as fast as, I mean, Tomcat(+Spring+Hibernate) served up 8x more req/s than the Rails solution did.

I made sure that, a) the returned size of each page was exactly the same, and b) I did comparable actions in all tests.

Anyway, I'm not making this stuff up. Plain Old Apache serving up the same file (as in, the end result of saving the output of the Rails/Java web app) managed 6,000 req/s.

Put in FastCGI and run the Rails app in a 'production' RAILS_ENV, with caching on, and that speed (all that's being rendered is a view using a layout. There is no DB access [for this figure.]) drops down to 62 req/s. This didn?t drop by much when accessing the database (56 req/s.)

The same page is served by Tomcat at around 500 req/s. (with database access + Hibernate = ~300 req/s.) Did I mention that PHP outperformed all options, serving up 1200 req/s (800 req/s with DB access)? That doesn?t mean I?d use PHP for any serious web development. :-)

I also tested mod_python: 200 req/s (150 with DB.) I tested mod_perl; 500 req/s (~300 req/s with DB.) I should also test ASP.NET/Mono.

I don't really see how this is huge news or anything. Ruby isn't/wasn't designed to be faster than Java, and given enough memory/CPU, Java can and does outperform C (the same page in static JSP running under Resin and the JRockit VM gets served at 10,000 req/s. Awesome. I even added a timestamp to the output just to make things a bit more dynamic, and the throughput stayed the same.)

I'm not claiming this is a revelation. Or that it's a fundamental design flaw in Rails (unless you think Rails? greatest strength; Ruby; a design flaw.) I'm just saying, you have to evaluate whether productivity or pure performance is more important to you, do your own benchmarking and testing, and then choose the most appropriate platform to develop your application.

In this particular instance, I personally don?t have the money to rent/buy more servers, so I need as much performance as I can get for my money. And since this is a ?personal? project, I don?t mind that it takes longer to do the development work in Java.

But if I was writing an Intranet app that didn?t need great throughput, then I?d be writing it in Rails, because it really is the best option available right now for quick and easy web app development. And at least it enforces things like MVC, so I mean, why complain when it can and should kill PHP (the speed of PHP drops dramatically when you start doing things like templating, or attempting MVC in it, and it?s definitely not as refined from a language design point of view as Ruby)?

Plus, the Ruby language (I think this should be getting some of the Rails limelight) is extremely elegant and a joy to work with (I?ve been doing Ruby development for a few in-house apps for the last 8 months?)

As they say, to each their own. Take benchmarks with a grain of salt, compare all options, etc, etc. The benchmarking I did demonstrated what I needed to know for my particular needs. The Rails app felt as responsive as the Java app with only a couple of users. So I don?t really know how it would feel to actual, living, breathing users (maybe the guys over at 43things can let us know how they're managing the load -- that'd silence the critics, wouldn't it?) and not some benchmark application. Maybe it wouldn?t be noticeable. Who knows.

I just wanted people to do actual tests on these things, because performance does matter, and it was not addressed by anyone over at the Rails camp.

I?m not taking sides, and I doubt anyone really cares. Maybe I coded the Rails app badly (well, this is why I didn?t do anything except render a view; to eliminate that possibility)? Maybe I didn?t set up the Rails app properly (well, uh, let?s see, it was running, and serving pages, and FastCGI was telling me it was doing so, and my production.rb has caching set to true, so I don?t really see how far I could have gone wrong setting it up, it isn?t that difficult. And yes, I was using the C fastcgi extension for Ruby. The pure ruby version didn?t work at all [using Ruby 1.8.2 final].)

It just seems to me that people are jumping on the bandwagon (from both sides) and decrying anything the other side says without first testing things themselves. I personally don?t find Rails revolutionary, nor do I worship at the altar of DHH (I don?t really see the revolutionary UI/functionality nature of BasecampHQ. In fact, it?s pretty crap. As for Ta-Da List, well, I don?t know about you, but not providing a login dialog anywhere on your website [yeah, they fixed this now, but it was like that for a few weeks] is probably a sure fire way to not get your users back. Woo, usability experts!)

Then again, I find Java (and its web app related by-products, such as deployment descriptors, the 500 different frameworks that all promise to be the holy grail of web app development, etc) too verbose and extremely hard to distil for your average user.

If you want more people raving about Java web app frameworks, then make them as easy to use (and understand) as Rails.

Sorry for the rant.

Posted by rlx on March 03, 2005 at 04:28 AM MST #

As a side note, The Great Computer Language Shootout compares the speed of Java and Ruby at various tasks.

Two results of particular interest are the object creation benchmark, and the object method invocation benchmark, which seem to at least show an order-of-magnitude difference between Java and Ruby performance.

So, it's not at all far-fetched that Rails could be 8 times slower.

Posted by rlx on March 03, 2005 at 04:54 AM MST #

At the last Java symposium I was at, Bruce Tate stated that he re-wrote an equivalent Java app in Ruby in about 1/8th the time. Is this a coincidence?

Posted by mr.me on June 06, 2006 at 08:51 PM MDT #

hey!

don't forget that all ruby/rails performance problem are all by the slow official interpreter. Sun has a seriuos work with the jruby guys and now netbeans came with full support for that.

The rails community are waiting for the new implementation of the interpreter, like YARV or JRuby.

Ruby on Rails can't die, because many developers love's the way in that the ugly things are getting simplifed. I just matter of time when Rails have the interpreter that deserve.

Cheers!
José Antonio

PD: Anyway i like the simplified appfuse aproach. You Matt make a great job! please take a look at the rails code generators to improve your appfuse. Use scripting instead of ant or maven for generators stuff!

Posted by josé antonio on November 11, 2007 at 06:44 AM MST #

Rails gets the interpreter it deserves? Rails can scale? Let's have one thing straight: Rails can handle exactly one request at a time. It deserves nothing except a pat on the back for popularizing an old Smalltalk concept and maybe a rewrite. The way large Rails sites scale is to throw tons of servers at the problem. While it's true that this is a type of scalability, it's also a long-term maintenance cost (something Rails fans seem to disregard). I won't argue whether Rails makes programmers more productive (I have doubts about this too, but it's not really important) but the cost of programmers is not such an overwhelming concern that all other costs should be thrown out the window.

The writing of the software is mostly a one-time cost. The running and maintenance of these servers is a recurring cost that can't be avoided, even if you do nothing else to the software. It won't take long before all the theoretical money saved on programmers is eaten over and over again by maintenance and fees associated with hosting those servers. Hosting a single server can be done for around $70/mo. Eight servers will take a half-cabinet costing at least $300/mo. Then there is the cost of the servers themselves, replacement cost for parts, *staff* to maintain them (and sysadmins are quite often more expensive than programmers), additional hardware in the form of switches and load balancers, etc that must be added.

Anyway, if people long to use Rails, good for them, but I'm getting tired of hearing "Rails scales fine" because it's a highly misleading statement. When management asks you if something "scales" they usually mean "will it cost us our entire IT budget in hardware and sysadmins to run it". With Rails the answer is "maybe."

Posted by Cliff Wells on December 26, 2007 at 12:06 PM MST #

Post a Comment:
  • HTML Syntax: Allowed