Cocoa and Objective-C: Up and Running (by me) is now available from O'Reilly.

Does Ruby on Rails Scale?

Wincent Colaiuta subtly alludes to the idea that Rails doesn't scale, or really that you need to provide it with a lot of hardware to do so. Now, I really don't have any hard data to say whether this is true or not, but for me it's somewhat beside the point.

The simple fact is that most development — web or otherwise — takes longer than is initially expected. A lot of this is due to building basic infrastructure that has nothing at all to do with the application. The fact that Cocoa provides much of this infrastructure for you is part of the reason Mac developers are often so productive in small teams.

Additional abstraction often takes more CPU time. But if you can get a Rails app up and running in a fraction of the time of another framework, and have a more stable base in the process, how much does the additional hardware cost really matter? I have exactly zero Rails apps deployed and running today, but I think that's where my future development will be.

Some people will drive 20 miles over the course of a half hour to save $2.50. This has always struck me as odd. First, you're paying for gas, oil and so on for your car. Second, your time is worth money. If you bill out of a rate of $100/hour and it takes you an hour to save $10, you've lost money.

In the same respect, if you use a less-abstracted framework to develop a web application so you can deploy it on cheaper hardware, but that software decision means initial development takes longer and changes to the application later are more complicated, is that really a good business decision? A lot of the same criticism about speed and indirection was aimed at Cocoa and Quartz when Mac OS X first came out. Yet look where things stand today.

What if you're given an option between a Rails app which takes a bit more CPU power, and an app written with another framework which never actually ships? I'll take the slower version that exists over the efficient one that does not.

The engineering purist in you may want the most efficient algorithm, but unless you're doing it as a science project, the real goal is for the thing to be up and running and for the user to be happy. If additional CPU power gets you there, so be it. Of course, there are extremes in both directions. The goal is to find the sweet spot.

Of course, another possibilty is that Rails scales just fine.
Design Element
Does Ruby on Rails Scale?
Posted Feb 06, 2007 — 28 comments below




 

Caleb Elston — Feb 06, 07 3511

Spot On. Most apps will never make it past the 1 or 2 box setup anyways so the hardware point is moot, and if you do make it past that inital hurdle, you would need to refactor your code to scale up anyways, so having a clean, easy to modify codebase in RoR will make scaling easier and faster, which will keep your customers happy.

Bill Gates — Feb 06, 07 3512

I suppose you mean "purist" at the beginning of the last-but-one paragraph.

It's not that I enjoy correcting mistakes and it makes me somehow feel a better person, but "purest" is also a word, and it had me staring for a few seconds, trying to figure out what that was supposed to mean there.

Feel free to delete my comment after you've made the correction.

Ben — Feb 06, 07 3514

As with everything, it all depends on what you're doing with the app. If you're shooting to be the next myspace.com with hundreds of millions of users, RoR in its current implementation is going to give you some real headaches, so you'd better be sure it's worth the saved development time.

If you're never going to scale past a few thousand users, then, yeah, who cares?

The trend on the desktop is that the inevitability of faster hardware and more efficient runtimes almost always trumps perf problems introduced by the next-higher-level framework. Cocoa apps may have been dicey on an ancient G3 under 10.1, but those users age out without your help, and now users can't perceive a slowdown and the turnaround time for coding is still really good. The same mostly goes for .NET on Windows.

On a server, though, when everything's against the metal and you own the whole stack, time alone won't age out user base-- a RoR server that can handle only 20req/sec today (say) won't magically be able to handle 2000req/sec two years from now unless the box is either upgraded or the software on it is upgraded, both of which imply a very real maintenance/IT cost. If you multiply that across lots of servers, it gets even harder.

Ruby people are spending some time optimizing the Ruby runtime, and surely the Rails folks are doing the same. It's still a somewhat dicey bet for a service (less so over time), but it certainly makes a lot of sense for rapid turnaround/simple deploy stuff.

Besides, in this heady Web 2.0 world, sometimes making that tradeoff in favor of faster time to market is necessary just keep your company afloat *now*, even at the later significant cost of more hardware.

Kay Roepke — Feb 06, 07 3515

I have to second Ben.

Although even with "Web 2.0" sites, I have yet to see a Rails application (or any ol' Ruby app for that matter) that scales. Everything I have seen until now just doesn't cut it, which is shame.

Some none-core parts of our application, a social network, are being written in Rails and IMHO they can be grateful that they don't get the total hit from the users, because then it would just explode.

If you have to get down to fine-tuning the queries to even minimize index scans, pretty much all the saved effort in the application development vanishes, and you're writing a lot of code to just keep it being fast enough.

Sure, Rails makes a lot of stuff easy, you're very quick to have something working, but if you're talking about writing big web applications, you either already have some sort of framework, or you will be writing one that exactly suits your need.

And, Ruby ain't exactly fast, which AFAIK stems from the fact that it isn't bytecode compiled yet. That's a major bummer, and I'm not sure when that'll be changed. Until then, I know that I won't consider it for anything that must scale up to thousands of concurrent users, saved development time or not.

If it doesn't scale, then it's out for big installations, but I'm all ears for someone with different experiences.

Arne Khl — Feb 06, 07 3516

So creating web-apps isn't all about being up with it fast. It matters, too how fast you can advance, change and keep up with your customers needs. So RoR is really the best solution to that, in my opinion.

Hardware is really cheap and your time not.

Scott Stevenson — Feb 06, 07 3517 Scotty the Leopard

For what it's worth, I realize there are extreme cases like Apple, Amazon, Google, and so on. I don't think most people are in this category. The big guys can also afford to manage the complexity of large applications. The group I'm talking about is made up mostly of smaller teams. In that case, I think you're better off using a more abstracted solution and investing in hardware if necessary.

In other words, don't chase efficiency for the sake of being efficient. Having an application which works but potentially needs more hardware at least gives you the option to deploy. I suspect that if we were to graph how many web-based software projects are never completed versus how many outstrip available hardware, the data would speak for itself. :)

@Ben: Cocoa apps may have been dicey on an ancient G3 under 10.1, but those users age out without your help
Good point, though I'd also add that the OS and the frameworks got faster as well.

Kay Roepke — Feb 06, 07 3518

Scott,

I don't think most people are in this category. The big guys can also afford to manage the complexity of large applications. The group I'm talking about is made up mostly of smaller teams. In that case, I think you're better off using a more abstracted solution and investing in hardware if necessary.

Yes, of course there are extreme cases and of course there those applications that don't have millions of page impressions a day.

But then there are lot of medium sized applications that are popular and those won't scale at all with all I have seen from Rails. Those were the applications I was talking about.

In other words, don't chase efficiency for the sake of being efficient. Having an application which works but potentially needs more hardware at least gives you the option to deploy.

Of course, efficiency isn't all there is, but in most cases it does make a difference. I have some experience with website scaling, bringing from a few hundred visitors a day to tens of thousands concurrently. That's not an easy task and involves a lot of tradeoffs. And in my experience, for a site to be successful, you cannot compromise on response time. If it goes up too high, you will not be attractive enough for customers and will not be able to reak in the necessary monetary units to pay for all the hardware you need (and traffic bills, power, etc.).

Hardware might be getting cheaper, but there are problems which you simply cannot solve just with more hardware - that's one fallacy I have seen in real life more than once.

Every piece of software written is a commitment, even a Rails application. When you see that it might not scale in a few weeks time you might be out of luck, because you simply cannot make it run faster if the bottleneck is execution speed. Investing in servers that run twice or thrice as fast is probably not feasible in a startup, so that's a real world problem.

Don't get me wrong, I'd really like to see it perform - but IMHO it's not there yet. At least not for larger installations. Of course that shouldn't keep people from using it in smaller projects. Learning is a good thing :)

MJ — Feb 06, 07 3519

It depends on where you need to scale it to.

Ruby does not scale for my needs. It's fine for user led transactions - like where the unit only works when you click, in real time. As oppose to moving in "computer time" where a millionth of a second is a lot of time.

Scott Stevenson — Feb 06, 07 3520 Scotty the Leopard

I have some experience with website scaling, bringing from a few hundred visitors a day to tens of thousands concurrently
So what would you recommend? In other words, what's a good balance of performance and developer productivity?

Mr eel — Feb 06, 07 3521

I've come across this argument many times. I use Rails in my job. We build applications for small teams. The framework lets us complete applications much more quickly than other alternatives trust me, we've tried.

Weather or not Rails scales is actually irrelevant to us. The savings in time and development cost is much greater than the cost of additional hardware which incidentally we don't need at the moment.

All this seems to come from some fetish with 'teh enterprise'. Somehow Rails isn't legitimate because it doesn't scale. Never mind the many healthy businesses built around it.

Overall I think Wincent is being a bit cheeky.

"Now this, 4,000 requests per second. Of course if you throw enough money at the problem Rails will "scale". But didn't we already know that?"

That's heavy traffic! Any framework is going to need additional hardware to deal with it. It's not as if replacing Rails with some other framework will immediately obviate the need for all that hardware.

Yes, some other framework may reach greater heights of efficiency on the same hardware, but really is that even relevant? What does greater efficiency mean if it costs you more to build and maintain your app, but hell, at least your hardware costs are lower?

Kay Roepke — Feb 06, 07 3522

So what would you recommend? In other words, what's a good balance of performance and developer productivity?

In my experience what really makes a difference is to try to plan ahead. Whenever we implement a new feature or have to touch some existing stuff we ask ourselves the question: "Will it handle the ten-fold load?"

It doesn't matter if it just barely handles that much, but if it's still acceptable, then we can do it. If it doesn't it can't be done that way.

We do the majority of our coding in Perl and by now have an extensive home-grown framework, which is now in its fourth incarnation. But there are areas where Perl doesn't cut it anymore, so we are moving some stuff over to Java and C. Granted, those are very specialized areas we do this, but in some cases it's necessary to be able to pass the "10x rule".

Why "10x"? Sounds like a stupid rule at first, doesn't it? Sounds like "you don't need that much performance reserve". But in my experience you will be distracted by other work long enough until you almost hit the limits of the system. And then you'll be grateful for every week of extra development time you have when it becomes a problem.

The time you bought by "oversizing" the solution a bit (or sometimes a lot) gives you more time to implement the features customers want.

Of course the whole lot of good coding practices apply here, too, to make you more productive. But in the end, constant refactoring is the real key factor. If you let code deteriorate enough, it will become a serious problem later on. Once you realize somethings broken, fix it. Or be prepared to throw it away a few months down the road...

Ben — Feb 06, 07 3524

Good point, though I'd also add that the OS and the frameworks got faster as well.
@Scott: Absolutely they did, and that's Ruby/Rails' real hope in seriously scalable service deployment. The fact that everyone and their mother is trying to build stuff on Rails right now is a really good sign-- it means that there's a lot of incentive to make it faster in the places where it turns out to be slow.

That being said, it's still true that your desktop app's users upgrade OS/frameworks over time and take care of the perf problem "for you", whereas in a service, you are responsible for the maintenance required to take advantage of framework improvements. And building/maintaining real services can a monster pain in the neck even when things are going well, so there's a cost there.

Michael Stroeck — Feb 06, 07 3525

I'm probably making an overly bold statement here, but five years from now, the majority of new web applications will be hosted somewhere out in the cloud from the get-go. We should all be working on how to make that transition, rather than bickering over which framework scales best.

Data centers are already taking on the physical (cooling towers! remote locations! national security!) and logistical characteristics that are typically associated with electric power stations -- computing power is becoming a commodity. Pretty soon, you will only be limited by how fat your pipe into the grid is. Scaling will mean someone halfway around the world plugging a standard shipping container full of equipment a handful of wall-outlets...

Kay Roepke — Feb 06, 07 3526

Scaling will mean someone halfway around the world plugging a standard shipping container full of equipment a handful of wall-outlets...

Bold statement or not, I don't think that approach will lead to anywhere, sorry. Scaling is one thing, efficiency is another. If you just throw hardware at problems, the thing will not perform. Programming is about tradeoffs but as energy prices are rising (and that's what they'll keep doing, at an increasing rate) using less computing power for the same output is a competitive advantage...

Michael Stroeck — Feb 06, 07 3527

Bold statement or not, I don't think that approach will lead to anywhere, sorry. Scaling is one thing, efficiency is another. If you just throw hardware at problems, the thing will not perform. Programming is about tradeoffs but as energy prices are rising (and that's what they'll keep doing, at an increasing rate) using less computing power for the same output is a competitive advantage...

No need to be sorry ;-) I was specifically not talking about efficiency. That's more a function of programmer competence than anything else. Apart from that, efficiency close to the silicon (which you seem to be talking about) will increasingly be provided by the people who write the big frameworks, and those who map your requirements to a virtualized environment.

The point is, the vast majority of developers may soon not have much of a choice. They will have to abandon custom hosting environments and hand-optimized code and move into abstract frameworks and virtualization, or be overwhelmed by development and hardware costs. That's just my personal generalization of the trends I see happening over the next 5 years. You don't have to agree, obviously :-)

Davide — Feb 07, 07 3533

Isn't Base Camp based on Rails (better, as far as I know, it IS rails)? Basecamp has a decently sized user base, or hasn't it?

Manton Reece — Feb 07, 07 3535

Yes, Basecamp was the original Rails app and has over one million users as of this week. Last time I heard, Basecamp was powered by 2 web servers and a single db server, but they may have added more boxes since then. I also believe they offload a bunch of file stuff to Amazon now, but that's more of a disk space issue than a Rails scaling one.

I've been developing in Rails off and on for a couple of years. I still use PHP for the occasional quick dynamic page when I just need to throw something up on Dreamhost without worrying about deployment, but I would hate to build a real web app without Rails.

Patrick Crowley — Feb 07, 07 3540

To the people who still live under a rock, yes, Rails scales.
Not satisfied? Keep reading. :)

James — Feb 07, 07 3541

I've not yet tried to scale a Rails site to any serious degree. The only Rails sites I've worked on have a trickle of visitors as they're kind of spare time things. I have found it to be a very productive and tool for getting apps up and running though.

However over the years I have worked on a number of systems that needed to scale to differing degrees and on every one of them the first and most serious bottlenecks I've come across have been nothing to do with the underlying framework or technology choice but due to poor implementation and design based on that framework.

In that sense Rails is just as easy to misuse as anything else.

Daniel Peebles — Feb 16, 07 3587

Scaling or not is really up to whether people use good algorithms for problems. Obviously, if you use a dumb O(n^2) algorithm when an nlogn or an n algorithm would've worked, things will get unusably slow quite quickly. But that is as much of a problem in rails as it is anywhere else. Of course, if the framework itself provides slow algorithms, then it's silly, but it's in their best interest to do it right, and fast. Other than that, the difference between frameworks and lack thereof is in the constants, which means that throwing more hardware at the problem can overcome a "bad" (i.e. slow framework.)

Kay Roepke — Feb 16, 07 3588

I actually thought that Ruby's problem was that the interpreter does no bytecode caching...
I expect that the Rails framework is written using reasonable algorithms, i.e. I totally trust there are smart guys writing something like Rails. Who am I to question their capabilities?

It's just that each time I tried Ruby I thought it was awfully slow, nothing compared to Perl or Python (which I don't have too much experience with, though).

I'm not in the business of Ruby bashing, so if it turns out that Ruby 2 is fast enough, and I have a new project at hand that would benefit from using Rails - count me in.

Stephan Eggermont — Mar 01, 07 3665

Switching from ruby on rails to smalltalk with seaside and magritte will bring the same order of improvement that switching to ruby was, for complex apps.

christian — Mar 01, 07 3666

So far it seems like the familiar responses I've seen to answer Rails scalability issues are 1) buy faster hardware 2) redesign your application 3) don't worry about scalability as much as maintainability.

ripplin — Aug 10, 07 4567

I found another post which is worth looking at that discusses scaling the logger facility, much like twitter does it:

http://www.dotrb.com/2007/8/11/scaling-rails-with-sysloglogger

Roger Pack — Aug 20, 07 4571

from http://www.ruby-forum.com/topic/108421 it appears that RoR scales, if you have the resources [several machines, hardware balancer]. So that's good :)

roger — Aug 31, 08 6318

In retrospect I suppose Rails scales about as well as anything--you might need 3 or 4 times as many application boxes as you'd otherwise need, but we do what we can [and that's only if you need scaling--most sites really don't, and if you don't then rails is probably good enough].

Scott Stevenson — Aug 31, 08 6319 Scotty the Leopard

@roger: In retrospect I suppose Rails scales about as well as anything--you might need 3 or 4 times as many application boxes as you'd otherwise need

When you say "otherwise", which other language/framework/appserver do you have in mind?

landoblog — Jul 13, 09 6831

It would seem that this is an issue that keeps arising again and again and is not really an issue when you look into it. In my opinion any language scales as long as the people who are using it are technically capable. Yes it may be slower than some languages but it also provides some pretty cool features that allow you to code much faster, distribute over many machines and shard data much easier than others would allow (specifically the framework allows/disallows this). It also really depends on what the application is meant to be doing. If I required a lot of intensive processing of data then I would personally go down the Java et al route and do a little mix and matching to find the best tools for the job. Others might use it for both and have proof that it works fine. For creating web apps in an extremely fast time is what Rails is all about. I have written a well balanced (I like to think) article before looking into the pros and cons of rails so take a look if you want to at Rails Scales (Or Does it?)




 

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.




Technorati Profile
Copyright © Scott Stevenson 2004-2008