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 [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
