As mentioned in a previous post about url_for, sometimes Rails magic needs to be de-emphasized or eliminated to attain the performance you need.

Rails provides excellent statistics to help you see how your application is humming along.

While you can go into the depth with various tools, like wrapping Benchmark block around code to see how it performs, the hints about where to look are in the logs.

A sample action will generate the following information in the logs:

Completed in 1.77621 (0 reqs/sec) | Rendering: 0.10928 (6%) | DB: 0.50002 (28%)

The discrepancy between the completed, rendering and db times lets know that you have overhead hidden away in an action.

Unless you are doing serious processing, like generating a PDF or accessing a web service, there is an obvious place to start.

The objects you are retrieving with ActiveRecord.

Having had experience with Apple’s WebObjects, I was familiar with the overhead involved in retrieving and instantiating objects.

Instantiating is the key place to look first.

In my case, the performance issue only revealed itself when a customer using the page ended up with thousands of records, not tens or even hundreds.

This action was using a typical AR finder method, with conditions to affect the results based on user input.

In development mode I was able to view the query and craft a custom finder that relied on find_by_sql.

On top of that, I honed down the columns retrieved to the bare minimum.

By default, ActiveRecord retrieves all columns, which can add significantly to the overhead during instantiation.

You can go lower, by retrieving the values using the bare bones database connection.

In my case, that wasn’t needed - yet.