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 jeremy@weiskotten.com.

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:

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.

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.

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!