Scaling Rails
Posted by Joe on July 28th, 2008Mixx is built using the Ruby on Rails framework. (Rails is the framework. Ruby is the language.) If you pay much attention to the internet tech world, this is likely to raise one big question: doesn’t that mean scaling problems?
Unfortunately, Twitter’s various problems with scaling and reliability have thrown up a lot of FUD around Rails. After all, Twitter is the best known large-scale Rails application on the web, and it has undeniably had problems with both scaling and stability. (Though having worked with the excellent engineers that Twitter just acquired with their purchase of Summize, I feel confident that their problems will soon be a thing of the past.) A common meme is that Twitter’s problems are due to Rails, and that therefore it is impossible to build a stable scalable application using Rails.
Since I’m the guy who chose to use Rails for Mixx, I obviously disagree. Let me tell you why.
(In the notes that follow, I’ll talk about both performance and scalability. I realize that these are not the same. However, they are closely related, and there’s FUD related to both around Rails, so I think it worthwhile to cover them both in this discussion.)
- 80-90% of end-user response time has nothing to do with anything on the server - it’s in the design and implementation of the page.
This is the result of a study done by Yahoo!, as reported in Steve Souders’s excellent High Performance Web Sites (which I highly recommend - there should be a copy of this book in every web development shop). Most of performance is tied to issues like setting correct cache headers on images, reducing the number of objects on the page, and proper design of markup, CSS, and JavaScript. If you want your pages to load fast, look to your markup. (This is one of the many reasons that the first person I hired when I came on-board was Jason Garber, Mixx’s UI architect. And why I bought him a copy of the Souders book as soon as it was published.)
- Performance on the server is mostly a matter of design of the data stores, not of application code.
A typical web application involves retrieving data from one or more data stores, manipulating it in some way, and rendering the page to contain that data. Of these steps, the one that is most likely to cause performance problems is the retrieval from the data stores. A poorly indexed database can cause major problems, and the biggest performance gains on a well-written application are going to involve faster data stores and a smart caching strategy. But these issues are not unique to Rails - they are common problems to all web applications, no matter what language is being used.
(While I know next to nothing about the Twitter architecture, I’m willing to bet that its scaling problems have to do with data store design, not application code. If Twitter were translated into another language without redesigning those stores, I expect that it would have the same problems. Building systems that require putting together data from multiple collections, with each user requiring a different set of data, is a tricky data design problem, no matter what the language.)
- Rails supports scaling through duplication of application servers.
It’s easy to fire up as many instances of application and web servers as you need in Rails. Hardware scaling - throwing another box into the mix to partition load - is just as easy with Rails as it is with any other modern web application framework.
The limiting factor to this kind of scaling is the size of your database host - but that’s going to be the limiting factor no matter what application framework you have. And the same tricks used in other languages to overcome those limits work in Rails.
- Rails supports scaling through partitioning of the application.
Another typical scaling approach involves partitioning the application into sub-applications, each of which runs on a separate set of servers. This can be done in Rails as easily as in any other language.
- Rails optimizes for programmer time, not processor time - and that is the right choice.
I’m not saying that Rails is going to perform as well as languages such as Java. But Rails is optimized to make life easier for programmers, not computers. This is a common theme in the history of programming languages - a new language comes along that is easier for programmers, but less efficient in terms of processor time. There’s an entire blog post in that - and I promise to write it sometime soon.
- It is easy to write naive Rails code that performs poorly. That’s why we you shouldn’t write naive Rails code.
Clearly, any language can be used to write bad, inefficient programs. But Rails, which abstracts out the database to make database access transparent to the programmer, probably makes it easier to write inefficient code. It is easy to slap together a quick Rails application without worrying too much about the database - that’s the great strength of Rails. But to get performance, you need to pay attention to the details. That isn’t too difficult, and I’ll blog sometime about how we’ve done it at Mixx. But it is necessary.
(I suspect that this is another cause of the bad reputation for performance that Rails has. People throw together a quick Rails application, taking advantage of its ease in programming, and are then surprised when it doesn’t perform. But while building an application can be easy, we aren’t yet at the point where building a complex and highly performant web application is easy.)
And there it is. At Mixx, we feel that Rails will serve us quite well as our application platform. In fact, we have effectively bet the company’s future on this belief. I do not expect to be proven wrong on this - while Rails is not a perfect platform in terms of performance, and there are a number of improvements that could help (another fertile ground for a blog post), for our application it performs just fine.
5 responses to "Scaling Rails"