Professional Ruby on Rails™

13.1. Measurement

People have been writing software for over a half century now, and the following three facts about performance have proven true in nearly every circumstance:

• It's almost always possible to buy speed at the expense of storage space.

• People are actually quite bad at predicting which parts of a computer program are the biggest performance problems.

• Optimizing software too aggressively or too early is usually bad for the quality of your software.

Luckily there are ways to work around these issues. The basic approach is to start gathering data about the performance of your application very early in the process, to gain some background data for guidance when the time comes to fix the issues. This section discusses some tools for gathering that data; the next section covers how and when to mitigate some of the problems you discover.

13.1.1. Railsbench

In general, there are two steps to identifying bottlenecks in your Rails application:

1. Determine which page hits are slow.

2. Determine what part of the calculation of the page is causing the problem.

Railsbench is a solution to the first problem. I should clarify here that the performance issue I'm referring to at this point is the server-side time spent turning the HTTP request into an HTML response, not the bandwidth time spent getting the HTML and images down to the browser. This doesn't mean that the bandwidth issues are unimportant (the user doesn't care where the slowdown is), but they are somewhat easier to diagnose ...