Last month, an old entrepreneurial colleague dropped me a note regarding some speed bumps he's hit while courting potential investors and partners...
"I've heard a few people mention that they heard that Rails doesn't scale [...] any suggestions on how we might alleviate their doubt?"So I rallied the troops (his two contractors) and we set out on a little informal fact-finding mission. Here's what we've come up with thus far...
How 7 Mongrels Handled a 550k Pageview Digging
Not a lot of in-depth analysis here, just an impressive scaling success story with a pretty bar chart of the traffic load and an itemization of the hardware and software involved along with costs.
It's boring to scale with Ruby on Rails
Granted, this one is written by the man himself, Mister Rails, so you have to take it with a grain of salt, but he hits upon the common themes, which are caching, load balancing, and:
"Scaling the database is the `hard part'"Unfortunately he gets a little off track in the second half of the essay and goes into the cost analysis of productivity and happiness, which is where you'll lose the attention of most investors.
Scaling Twitter: Making Twitter 10000 Percent Faster
I love the High Scalability blog; it's the dessert of my weekly reading. Granted Twitter still has its problems to this day, but you can't deny its monumental achievement in wide-spread adoption and ungodly levels of traffic. In addition to the aforementioned staples of caching, load balancing, and database optimization, they add partitioning and queueing to the mix.
Engine Yard Bets Big on Rubinius
What does this have to do with the scalability of Rails? Well nothing explicit in the article, but it supports two important movements that will eventually lead to a greater good.
First of all, Rubinius is one of three now mainstream Ruby implementations (the other two being Matz's original and Sun's JRuby). Competition here is good. This means better, faster, more stable Ruby environments, which will translate into a faster and more stable Rails.
Secondly, Rubinius is eventually going to lead to mod_rubinius, which will lead to even more scalability of the Rails platform by allowing us to leave separate single-process servers (like Mongrel) on the wayside.
Personally my money is on JRuby (and Glassfish) for the long haul; if you haven't checked out Glassfish yet, you're doing yourself a disservice!
Benchmark Invests in RoR Provider
Pretty much a no-brainer here. Benchmark Capital invested $3.5 million into Engine Yard, whose main business is Rails hosting.
Riding the Rails with WebSphere
If Glassfish is a little too cutting-edge for you, and you're all about being "enterprisey", then IBM's WebSphere is probably right up your alley.
At this point, between IBM and Sun's support of Ruby and Rails, and the multi-million dollar investments other Rails-based ventures are receiving, I'm beginning to wonder how savvy are these potential investors my friend is getting flak from.
But we're not done yet...
Can Rails Scale? Absolutely!
This article is a pretty good round-up of the more recognizable names using Rails, such as Yellow Pages, Basecamp, and the infamous Twitter, as well as a rehashing of the same old story: caching, spreading the load, and tuning your database.
Friends for Sale Architecture - A 300 Million Page View/Month Facebook RoR App Todd Hoff's picture
Here we are again at my favorite feed, High Scalability, with another Rails scalability success story. This time it's a Facebook app, and a rather popular one at that. I won't spoil the surprise for you, because their is no surprise -- it's the same old story: cache, distribute, and:
"The most important thing we learned is that your scalability problems is pretty much always, always, always the database."
So in summary, there's plenty of good ammunition out there against the naysayers.
7 comments:
Rails is slowly (no pun intended) getting past the stage where people argue that it *cannot* scale. The kernel of truth that keeps this debate going is that, all other things being equal (designer and programmer talent, etc), a well-designed Rails will scale less than a well-designed Java or .NET app on the same hardware. (Not starting to start a flame war here; I know that differences in the difference would be negligible for almost all users.)
What you term DHH's "off track" time is really the main point: even if Rails does not scale as well, this was an intentional tradeoff: more machine cycles for less developer cycles. If you need every last machine cycle, Rails is not for you. If you are like most users, however, you will benefit more from the balance Rails struck. Rails correctly forecast that computers are always getting better/faster/cheaper, but good brains are always going to stay expensive. Unless you need maximum scalability on fixed hardware, you may well get the best bang for your buck by investing in the brains, staying nimble, and riding the wave of hardware improvements if and only as you need it.
Any web stack can scale if you throw enough hardware at it. It is the cost of scaling that is the question and I imagine the item that most people are concerned about.
Along with scalability, there is availability. DHH's admission to Zed Shaw that their own Rails servers go down 6 times a day is just unacceptable for many.
Servers should not go down, unless there is a hardware or infrastructure failure. Ever. Hopefully Rails can answer these questions in the future.
Just for the record, our servers never "went down 6 times a day". We restarted our Mongrel processes when they reached a memory ceiling (that we set) ~6 times a day before that fix to threads got into Ruby.
Now we don't restart our Mongrels like that any more.
So a) there was never a crash issue, but a memory leak and b) that memory leak was plugged long ago.
Thanks for playing, though, Graeme.
Pleasure, thanks for clearing that up, perception is often not the truth ;-)
DHH, that you think that answer is satisfactory is really what's most troubling.
Meh, I think DHH's comment is honest. Mongrel was/is relatively young and probably does have leaks in systems where you encounter massive numbers of page views.
How are you gonna fix leaks like this? By installing them at places like 37signals and letting 'the big boys' find the memory leaks.
Think that's what he was trying to say.
Way too many people put stock in zed shaw's post. Zed shaw is a smart guy, but he comes off as a major complainer with an unproductive attitude.
I vote for developers over hardware :)
Post a Comment