Channels ▼


Performance on Rails

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 ( or NewRelic RPM (, 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.


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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.