[Mongrel] Recommendation: Faster Can't Help 2

Carl Lerche 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?

-carl

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
> advice.
>
> 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
> faster!"
>
> 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
> anyway.
>
> 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
> change.
>
> 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
> expectations.
>
> 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.zedshaw.com/
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



More information about the Mongrel-users mailing list