views:

748

answers:

5

I'm not going to make this into a Rails vs Framework X discussion, there's plenty of those already. After seriously contemplating what framework I'm going to use for my next deployment, I decided it's very difficult to pass up the out of the box REST exposure Rails gives you for minimal work back. This is something that requires slightly more work in Django, and considering I'm putting mostly emphasis on the API portion of the app, Rails makes more sense this time around. Considering how important it is for me to write an app that contains heterogeneous clients (iphone/android/tablets) that can access (not just web browsers), I need to be able to build RESTful APIs with minimal resistance from whatever framework I'm using.

My question is, is Rails ready to handle not a Twitter sized app, but something that does roughly 75,000 unique hits a day? Does Ruby 1.9.1 really improve things? There's plenty of nightmare stories and equally as many success stories depending on who you ask. Joel Spolsky (one of the founders of stackoverflow.com), believes Ruby itself is just not ready for prime time because it's still considerably slower than other interpreted languages. I'm not worried about getting to Twitter's size (that's a problem I wish to have one day), but on the same token, I do have a site with an average of 75,000 unique users a day. I'm wondering what kind of scaling issues I'll run into by deciding to use Ruby 1.9.1 + latest Rails (CPU costs + memory footprint) as part of my API stack vs. just taking the time to actually do a little extra work in Django to build a RESTful API. As Joel mentions in his article, I don't want to buy 100 servers when I can buy 10. I would love to be convinced as to why Rails is now ready to meet my requirements.

+2  A: 

It's not really a question of whether Ruby 1.9 is ready for Rails, but rather if Rails is ready for Ruby 1.9. From what I've read, it seems like Rails itself (ActiveRecord, etc) runs well on it. You may have issues with any ruby gems you may use which are not 1.9 ready. Check out http://isitruby19.com/ to see if anyone has commented on the specific gems you are using.

Beerlington
Rails 2.3 and up is compatible with Ruby 1.9 . Their last update, 2.3.5, fixes (paraphrased) "issues with Ruby 1.9 which you most likely would not notice since they're so small".
Trevoke
+1  A: 

My question is, is Rails ready to handle not a Twitter sized app, but something that does roughly 75,000 unique hits a day?

What server are you using? What does each request do? If you are running on a single core 128meg slice then probably not.

Ruby 1.9.1 is indeed much faster than Ruby 1.8.X and it is also less memory hungry. 1.9.2 is around the corner, in fact, Rails 3 perform all their Dev work on 1.9.2 trunk.

On my server I am able to handle 80k page views a day without breaking a sweat and without implementing any sophisticated caching, if I built some smart caching with redis or memcached I would feel comfortable serving 10-20x that amount.

You can design wonderfully performing web apps with Ruby and Rails (Even on REE 1.8.7). You can design horribly performing web apps written in C++.

If you understand your platform and know how to optimise, you can get great performance.

I would probably stay away from Ruby 1.9.1 (unless you consider yourself a Ruby expert) purely due to a handful of libraries not working and the fact the the vast majority of Rails apps out are not running on it. I tried 1.9.1 a few weeks ago and was able to get my app to work, but it did require a bit of Ruby foo.

Sam Saffron
+6  A: 

We experimented with 1.9 a couple months ago and we were so impressed by the speed improvements that we almost immediately began the process of migrating over to it. The only libraries that did not run smoothly were Facebooker, which one of our developers was able to patch in a couple of days (The plugin is now fully 1.9 compatible), and VPim (iCalendar library) which we were able to switch out easily with the much newer RiCal plugin.

Rails 2.3 is absolutely ready to run on 1.9 and in our experience resulted in a greater than 60% improvement in request times. Our integration tests also received the same benefit. We had 1200 tests that tool 300 seconds to run now taking only 110 seconds with no other changes except switching from Ruby 1.8.7 to Ruby 1.9.1. This also means we were able to double the amount of load each of our servers could handle.

It's certainly possible that you use a gem that is not 1.9 compatible, but the vast majority of them are or can be made compatible with minor changes.

You will definitely not experience any issues with 75,000 unique visitors, and a single server should be able to host a rails application with at least ten times that level of traffic unless your application is written very poorly.

Gdeglin
I agree that 1.9 is impressive, but seeing that only 2 versions ago passenger started working and still quite a few gems do not work, or require special care (eg. mongrel) I would not be handing out a recommendation to a newbie to start on 1.9 to solve a performance problem he/she does not have.
Sam Saffron
+4  A: 

Joel's post is from TWO THOUSAND AND SIX. That's FOUR years ago. Things have changed, thankfully :) Ruby 1.9 is ready for prime-time. It's compatible with Rails 2.3.5, and Rails 3 is built with Ruby 1.9 in mind, so it will be fully compatible with it.

"My question is, is Rails ready to handle not a Twitter sized app, but something that does roughly 75,000 unique hits a day?"

That's roughly like asking if you think ten thousand eggs would help you make an omelet, not for a town, but for a family.

Trevoke
I like your analogy: the answer is of course **no**, since we know chickens do not have scales, therefore eggs can not swim - QED
Sam Saffron
+1  A: 

You shouldn't have an issue with Ruby 1.9.1; I just wanted to take issue with this:

75,000 unique users a day

It means precisely nothing. We don't know how many requests per second that translates to for your app. If you actually mean 75,000 requests per day, that's trivial - it's less than one request per second. Any framework that can't guarantee you that before you hit limits imposed by the database or your app architecture has bigger problems than the platform it's running on :-)

regularfry