Don't Forget to Plant It! » performance

Running FiveRuns TuneUp in a Separate Environment

Calvin — Mon, 06 Oct 2008 01:23:24 +0000

FiveRuns’ TuneUp is a great tool for profiling your Rails app, but by default it is always running in development. This causes two issues 1) every request is slower in development as it is always collecting profiling data, and 2) the TuneUp bar can mess with the layout of your application, especially if you’re rendering content in iframes like we do with Skribit. So instead of having TuneUp always run in development mode, I’ve changed it to run only when the server is started in a new environment called ‘profiler’. Here’s how I did it.

First, you need to tell TuneUp to only run in the profiler environment. You do this by modifying config/tuneup.rb (create this file if it doesn’t already exist):

Fiveruns::Tuneup.config do |config|
  config.environments.delete('development')
  config.environments << 'profiler'
end

Next, copy the development configuration block in config/database.yml and create a new block called profiler:

profiler:
  adapter: mysql
  encoding: utf8
  database: YOUR_DATABASE
  username: YOUR_USERNAME
  password: YOUR_PASSWORD
  socket: /tmp/mysql.sock

Finally, create your profiler environment configs by copying your development configs:

cp config/environments/development.rb config/environments/profiler.rb

You’re all set! Now, to run the server with TuneUp on, just run the server in the profiler environment:

script/server -e profiler
Now, I have TuneUp available to me only when I'm looking to optimize performance.

Troubleshooting Performance Problems

Calvin — Tue, 10 Jun 2008 02:27:49 +0000

Skribit’s downtime last Monday got me thinking about my past experience with performance tuning. I’ve troubleshot a lot of performance problems in the past, and here are some things I’ve noticed:

It’s Never Just Because Pure Load. I’ve used this excuse many times before and still mutter it today, but I never truly believe it. If you hear yourself saying this, it should be setting off red flags in the back of your head. Look harder. Why is it never because of load? Because we don’t write perfect software. Deadlines happen, we can’t always predict how users will use the site, and we sometimes we don’t know how things should be designed until later. Basically, shit happens. Chances are there’s something in the software that’s misbehaving under load.

There are Long Term and Short Term Solutions. Depending on the immediacy of the performance problems, you might want to tackle the short term solutions first. It’s hard to fix the long term solution quickly and correctly when you have unhappy customers.

Know the Performance Problems You’re Solving. Don’t just guess at what the problem might be, try to figure out how to identify it. Check the logs and maybe the resulting data created. Try to predict how your site should behave when the problem is occurring and prove it out. Even if this takes some time, you want to make sure your changes fix the problem, and that if performance problem still exists afterwards at least you know you’ve correctly fixed one problem.

Caching is Great for Hammering out Performance Issues. I usually use caching as the first line of defense against load. Others like to tweak database indices, code, and/or configuration first, but my experience has been that caching gives you the most bang for your buck. However, caching is like cleaning up your room by stuffing everything into your closet – if you don’t go back and clean things up later, things will eventually come crashing down.