Will Ruby and Rails Scale?

Brian Wynne Williams, CEO & Co-Founder, June 22, 2007 2

“Can Ruby on Rails scale when my web traffic takes off like a rocket ship?”

This is a common question we get (or some variation). I have a simple answer:

“Yes, it can.”

As with any technology or framework, it’s easy to build something that won’t scale. Furthermore, there are applications where Ruby/Rails isn’t the right solution. However, we believe that Rails will scale fine if you make smart architecture decisions. Heavily-used apps like Basecamp and large-scale sites like Revolution Health show this; but, lately people like to talk about Twitter‘s problems.

Silicon Valley-based Powerset just announced that they’re building their front-end in Ruby (though not necessarily Rails). They addressed the question of scaling and Twitter’s situation with some first-hand insight:

We’re not worried about scaling.
So, inevitably, whenever we talk about Ruby or Rails scaling these days, someone brings up Twitter and its scaling problems in the past. Twitter is right down the block from our offices and I know several of the devs personally, so before we made a final decision I arranged a sit down with Twitter’s lead developer, Blaine Cook, to talk about the situation. Blaine was kind enough to let me bring along our Search Architect (and former search architect at Yahoo!) Chad Walters, our Head of Product Scott Prevost, and our COO Steve Newcomb, to poke and prod and get their questions answered. The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly-growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and, at that point, you have to rethink your approach. In an email he writes:

For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement; but, thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10,000% faster than it was in January.

Twitter’s explosion of growth in March certainly created pain points for them (gotta love slide 7 here) and a lot of lessons learned; but, it’s not an indication that the framework inherently won’t scale.

Our belief is that when building a web app, agility is more important that built-in scalability. “Premature optimization” causes more problems than it prevents. Focus on building a site that people will really use, then refactor and optimize over time as your audience grows. Rails is made for agility. You always hear about development speed, but test-driven development is easier and faster in Rails as well. Both factors mean that making architecture improvements to an already-deployed site is more practical.

Regardless of technology, build with scaling in mind, not necessarily built-in. Friendster didn’t scale, but that seemed to be a management decision. Had Twitter obsessed about trying to build for the number of users it’s supporting today, they probably never would have made it out of the gates. And then how would I possibly know that Darth Vader just ate a burrito?

Posted in Ruby on Rails on 06/22/07 2 comments

Gil said on 06/22 at 10:22 AM

The problem Twitter ran into is a good problem to have, but it is also not a common one. You’re right Brian...worrying too much about that sort of thing ahead of time might’ve been their downfall. They tackled the problem as best they could and everyone seems to have calmed down now.

On a side note, I hate it when people point to 37Signals and Basecamp as an example of how great Rails can scale, because it is not a good one. Basecamp is the type of app that’s easy to scale horizontally. Need to support 1,000 more Basecamp installations? Just plug in a new database and web server and direct all signups to the new cluster. Problem solved.

Twitter, on the other hand, has to scale vertically. Because of all the interconnectedness, it’s 10 times harder to split their one main database into chunks (sysadmins call them “shards") than it is for 37s to create tiny independent databases for each client and stick them anywhere they have room.

The real test of an application stack is how well it performs when you don’t have the luxury of scaling outward. Twitter seems to have gotten the problem under control, but at what cost? Was it more expensive than solving the same problem in Java, or .Net, or PHP? To me that’s the ultimate litmus test.
-----

Patrick Reagan - Director, Application Development said on 06/23 at 07:54 AM

@Gil - good point. When you have a generalized question like “Does Rails scale?,” I think it’s perfectly acceptable to say “Yes, look at Basecamp.” It’s a unique situation, yes, but each application presents its own unique problems when it’s time to distribute the load.

There seems to be a lot of FUD when it comes to Rails and scaling, but the advice that Cal gave at the Flickr workshop we attended applies here as well. Strategies like de-normalizing your database, caching (e.g. memcached), and pushing resource-intensive processes to off-peak hours can go a long way. Beyond that, there are other techniques like database sharding (which you mention), clustering, and replication out to optimized read-only slaves. The solution you use depends on where you want to spend your money - hardware or software (i.e. developer time).

As far as the cost issue, we’ve seen the same well-popularized productivity gains from using Rails for our custom built applications. Having the framework force you into MVC is definitely a good thing here. I can’t imagine how costly it would be to scale the typical PHP application where all the business logic is mixed into the view layer (something I’ve seen too many times when doing code reviews for clients). The clean application architecture that we take for granted in Squidoo’s implementation doesn’t seem to be on the radar of most PHP developers I’ve come across in the last 6+ years - scary!

Next entry: Campfire Culture

Previous entry: Cursor Keys in Vim: You Mac'ing Me Crazy!