If you've had a Ruby on Rails application up and running for a while, you may notice that it's not running as well as you'd like. This is when optimizing its performance can make a difference. This six-part article series will show you how. It is excerpted from chapter 13 of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).
We now have a working application, and people are already rambling in to shop at the Emporium online store. While George is very happy that the money is flowing in, he has noticed that the site is behaving less responsively lately.
Here, we will look at techniques for optimizing the application. This chapter is not about specific functionality in the application, so we won’t tell it in the form of user stories. Neither do we use TDD here, since we’re not really developing anything.
Performance and Scaling
Recently, the terms performance and scaling have been used interchangeably within the context of web development. Actually, they don’t mean the same thing.
Performance means how many concurrent users can use a web application and still consider it working fast enough. The “fast enough” part depends on the application and its use.
Scaling, on the other hand, is a totally different beast. To paraphrase the creator of Mongrel, Zed Shaw (http://www.oreillynet.com/ruby/blog/2006/05/ post.html), scaling should be more analogous to “resource-expandable,” meaning that you can start with a moderate hardware and software stack, and easily expand it so that the application is snappy, even if it gets Slashdotted.
An often-heard argument against Rails is that it doesn’t scale. People stating this often assume that scaling and performance are the same thing, and really mean that Rails is slow. Although Ruby as an interpreted, dynamic language is not among the fastest programming languages, that doesn’t mean Rails as a web framework is slow. The fact that 37signals ran Basecamp with up to tens of thousands of customers on a single box without any caching whatsoever should be enough to prove that Rails is fast enough for most uses.
There is nothing in Rails that would make it inherently hard to scale (scale as in being easily “resource-expandable”)—quite the contrary. Rails uses shared nothing architecture similar to that used by many very high-traffic websites like Google and Livejournal. Shared nothing is a distributed architecture consisting of independent nodes without a single point of contention. In Rails, this means that you can scale very easily by adding new application servers. If the pages are not rendered fast enough by one server, add another server next to it. Load balance requests between the two, and you have roughly doubled the performance of the application (depending on the database performance).
Ruby-on-Rails 
