Aaron K. Hawkins

The elevator door opened and I stepped inside.  It’s was kind of like if you’re at Disneyland and you find yourself standing alone in an elevator with the real Mickey Mouse, only you can’t remember his name.  You’re positive that you’ve seen his face before and maybe subscribe to his blog and that he probably is important or famous or something.  Who would pass up an opportunity to strike up a conversation?  Only it turns out that Mickey Mouse was really Donald Duck - you just didn’t recognize him.  And thats how I learned that Michael Koziarski isn’t Thomas Fuchs.

Despite my embarrassment, I still attended Optimizing Rails, a talk given by Michael Koziarski at RailsConf 2008.  This talk wasn’t about optimizing your rails application.  It focused on how to optimize the Rails Framework itself.  Optimization is a scientific process which requires profiling followed by fixing, repeated many times.  Short circuiting the process is the equivalent of guessing - and when we guess we are always wrong.  

He told a story about their Trac installation for Rails.  Their installation was above and beyond the normal traffic usage patterns of other projects and they were  having crazy performance problems.  Naturally they looked to the community for help.  People suggested lots of things.  They upgraded the database driver - no effect.  They tweaked some settings - no effect.  Finally they dug into the code to see what was going on and discovered that the svn revision number was stored in the database as a string.  Turns out there is code called multiple times on every page to calculate the most recent svn version.  Calculate is the correct word.  Instead of doing a simple sql query to get the max reversion number there was a method that would calculate the latest version number from a string (Hey - someone may want to use a Version Control System someday that uses strings as keys for revision identification - right?)  This implementation, combined with their high load was enough to bring the site down.  So they hacked it to store an integer and the performance problems went away.  The key lessons were that everyone else knew what the problems were but it wasn’t until they measured and profiled, and used a  scientific method that they found the real problem.  

This principle applies to optimizing Rails.  You can’t just guess and most people know that.  So naturally, they look for something to serve as a benchmark - and that’s the problem.  What is a good benchmark for Rails?  Many of the posts deriding Rails’s performance build a trivial hello world app and then benchmark it.  Michael showed a couple of different examples of benchmarking against a trivial program and the results.  Then he compared benchmarking one of his client’s applications and the results.  As you may guess, they were quite different.  What was a huge performance hit (say 15%) in the trivial case was completely irrelevant in a more representative application.

The Core Team does work on optimizing Rails by using their own applications as benchmarks.  While working on these real applications they find problems, bring them back to the group for discussion and finally add them to Rails if it seems like it might be a good fit.  He hinted that their time was limited, so it might be better spent working on tangible tasks like documentation, feature requests, etc, rather than blindly looking to optimize the framework.  I agree with this approach.  

We know that Rails was extracted as a framework from a real application.  I like the fact that the optimizations added to Rails are also extractions from real applications instead of just making theories and going with their gut to find performance improvements.  So the next time you think - “man Rails is inefficient or bloated or slow - why don’t those guys fix it” - go ahead and benchmark your application and see if the Framework is really the limiting factor.  You may be surprised by the results.