Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Web Development

Performance on Rails

Jeremy is a software engineer at PatientsLikeMe (www.patientslikeme.com), a social network and health-management tool. He can be contacted at [email protected].

You've built a cool new web application with Ruby on Rails (or similar framework) and released it to the world. Everything works as expected, but users are starting to complain about the app being too slow. And you're starting to regret following that mantra about "premature optimization."

Improving your web application's performance can be a daunting task, but it's an important factor in keeping users happy and productive. In this article, I present strategies for identifying common performance problems in Rails applications and ways to fix them.

The Strategy

The process of tuning the performance of a Rails app is not much different than any other software framework: Identify your biggest bottlenecks, remove them, and repeat until performance is acceptable. If this sounds familiar, you've probably performance tuned other applications built with another framework. Much of your experience will translate from project to project, framework to framework.

The performance characteristics of a Rails app in a development environment can be very different than a production environment. For example, class caching is enabled by default in production, which means that the code is loaded once and kept in memory until the application is restarted. In development, every class is reloaded on every request, which makes for a shorter feedback cycle to enable rapid, iterative development, but adds some noise to your performance metrics.

To remove this and other variations in performance, emulate the production environment as much as possible. The easiest way to do this is to simply run the application in production mode. If you edit your config/database.yml file and point the "production" environment to your development database, you can use your development database in production mode for profiling:

development: &development
  adapter: sqlite3
  database: db/development.sqlite3

  <<: *development

When you start your server in production mode, Rails will now use your development database:

$ script/server -e production

You'll just need to remember to restart your server to pick up any code changes because class caching is enabled in production mode.

You might also find that your svelte development database doesn't reflect the real world. To simulate a user's experience in the wild, test with a local copy of your production database (sanitizing sensitive data—social security numbers, credit-card information, e-mail addresses, and the like—of course).

There's one exception. I use the QueryTrace plug-in for Rails (github.com/github/query_trace) in development mode, but I don't deploy it to production. This plug-in logs the stack trace when each SQL query is logged, which makes it easy to pinpoint the code that's causing the query to be executed. In production it probably impacts performance (ironically undoing some of the progress it enables), so don't add the plug-in to your project's version-control repository.

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.