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@rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users