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.
Does Ruby on Rails Scale?
Posted Feb 6, 2007 — 28 comments below
Posted Feb 6, 2007 — 28 comments below
Caleb Elston — Feb 06, 07 3511
Bill Gates — Feb 06, 07 3512
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
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
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
Hardware is really cheap and your time not.
Scott Stevenson — Feb 06, 07 3517
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
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
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
So what would you recommend? In other words, what's a good balance of performance and developer productivity?
Mr eel — Feb 06, 07 3521
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
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
@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
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
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
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
Manton Reece — Feb 07, 07 3535
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
- Basecamp
- Odeo
- Strongspace
- Writeboard
- Penny Arcade
- 43things
- Measure Map
Not satisfied? Keep reading. :)James — Feb 07, 07 3541
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
Kay Roepke — Feb 16, 07 3588
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
christian — Mar 01, 07 3666
ripplin — Aug 11, 07 4567
http://www.dotrb.com/2007/8/11/scaling-rails-with-sysloglogger
Roger Pack — Aug 20, 07 4571
roger — Aug 31, 08 6318
Scott Stevenson — Sep 01, 08 6319
When you say "otherwise", which other language/framework/appserver do you have in mind?
landoblog — Jul 13, 09 6831