[Mongrel] Recommendation: Faster Can't Help 2
carl.lerche at verizon.net
Fri Sep 8 23:49:38 EDT 2006
Probably a "dumb" question, but what could be considered a good
number of requests / second?
On Sep 8, 2006, at 5:33 PM, Zed Shaw wrote:
> 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,
> common solution people tell you is that you need a faster server.
> 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
> 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
> 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.
> typically get obsessed with vanity number of performance and will
> way more time and effort than is economical trying to make their
> 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.
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users