Dr. Dobb's Journal - December 2008 - (Page 20)

d12weis_p4db 10/10/08 9:30 AM Page 20 Core Technology by Jeremy Weiskotten Performance On Rails Strategies for finding and fixing common performance problems 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 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. 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. development: &development adapter: sqlite3 database: db/development.sqlite3 production: <<: *development When you start your server in production mode, Rails will now use your development database: $ script/server -e production 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: 20 Dr. Dobb’s Journal l www.ddj.com l December 2008 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 plugin 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. Analyze and Prioritize A typical midsized Rails application has 10–20 database tables and corresponding model classes, a continued on page 24 http://www.patientslikeme.com http://www.github.com/github/query_trace http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - December 2008

Dr. Dobb's Journal - December 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Conversations The Man Who Sold the Sky Performance on Rails LINQ-to-SQL and T-SQL A Remote Java RMI Registry Beyond B-Trees File Descriptors and Multithreaded Programs Effective Concurrency The Agile Edge Swaine's Flames

Dr. Dobb's Journal - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.