Raible Designs

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

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

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

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

Posted by Mark Muday on February 28, 2005 at 03:11 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 #

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

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 #