[Mongrel] Recommendation: Faster Can't Help 2

Zed Shaw zedshaw at zedshaw.com
Fri Sep 8 20:33:20 EDT 2006

I hope everyone is getting something out of these recommendations.
Today's recommendation comes from the "Damn Common Sense" dept. of

Let's say you've written a really really slow rails application.  Best
you can get out of the thing is 2 req/sec.  What can you possibly do
about that?  It's a common problem for new rails developers.  Well, the
common solution people tell you is that you need a faster server.  "Buy
a 4 way Xeon!" "Litespeed is 2x faster!"  "See, FastCGI is sooo much

I'm here to tell you a different kind of advice.  The kind you really
need to hear:

You are a stupid moron who writes horrible code and you should fix your
damn pile of crap you call software before you waste people's time and
money on ass loads of hardware and software that will *not* help you

Don't worry, my code sucks too--at first.  Then I tell myself my code
sucks, I measure it, and then I tune the living daylights out of it.
Sometimes I just make a few small one line tweaks and get massive speed
improvements.  For example, Mongrel was sucking ass at serving files
lately.  I found out (through profiling) that for small stuff I could
just add three lines and serve the file directly.  Poof, mongrel was
fast again like magic.

Now I'm not saying *don't ever* buy more hardware and software.  Use
what works.  I'm saying your first approach should be to assume you're
an idiot and that there's something simple you can tune.  You'd be
surprised what a day of just tuning up a *working* application can get
you.  Sometimes it will mean you don't need to buy anything.

Once you've got it to be as fast as possible without any extra help,
you're at what I call "the tuning density".  A good sign you're at the
tuning density is when you run your program under ruby-prof you don't
see any place that's dominating the execution time or that you can't

THEN you can go buy all the stuff you need to get your application to
your measurable performance metric.

Ok, but there's a trap in all this:  take your meds first.  Programmers
typically get obsessed with vanity number of performance and will spend
way more time and effort than is economical trying to make their server
fast.  The way to avoid this is to set *measurable* targets and base
them on actual needs.  This does two things:

1) It tells you when to stop.
2) It tells you when you're screwed and could never meet the metrics so
you can just stop working on it in the first place or change the

There's a practical reason for doing this too.  Mainly, you have to
spend the money to test your hypothesis that the purchase will improve
performance.  Since your rails code is so poor there's a good chance it
won't improve it, but you can't tell until you've paid the money.  By
doing the work to tune your app to the tuning density before your
purchase you'll increase the chance that it'll help.

Zed A. Shaw
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

More information about the Mongrel-users mailing list