Analyze and Prioritize
A typical midsized Rails application has 10-20 database tables and corresponding model classes, a dozen controllers, and about 100 view templates. That translates into at least a few thousand lines of code. Now where are your bottlenecks?
Consider your application as a whole. What are the most popular page requests? Are there any obviously slow responses? If your app is small enough, you might be able to answer this off the top of your head with confidence. Otherwise, I suggest gathering some statistics about your application's usage and aggregate performance using a service like FiveRuns (www.fiveruns.com) or NewRelic RPM (www.newrelic.com), or build your own tools to mine some basic stats like frequency (how often a request is made) and duration (how long those requests took) from your logs.
Once you've identified your problem areas, prioritize them, starting with the most popular slow pages.
Benchmark
Before making any changes to improve performance, you should have a point of reference, a benchmark, to know how much improvement you've actually made with each change, or if you've caused a regression.
Load your slow page and see how long it takes to complete. The easiest way to do this is to watch your development log:
$ tail -f log/development.log
When you load the page, the last statement that is logged is something like this:
Completed in 3.05327 (0 reqs/sec) | Rendering: 0.87915 (28%) | DB: 1.49075 (48%) | 200 OK [http://localhost/foo]
This request completed in about three seconds, which isn't very good. Your goal is to make that number as small as possible, increasing the number of requests per second. That translates into a more responsive application, but also an application that will be easier to scale because you'll be able to handle more concurrent requests with fewer resources.
It's a good idea to run the same request a few times to make sure the metrics are consistent. There may be some outliers due to garbage collection or other system activity—ignore any outliers and find an average response time.
In the aforementioned example, the rendering time is on the high side, but almost half of the time was spent executing database queries, so I want to focus on that.
