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.
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
" Best you can get out of the thing is 2 req/sec " On 9/9/06, Carl Lerche <carl.lerche at verizon.net> wrote:> > 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 > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- nothing much to talk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060909/5687dc5b/attachment-0001.html
On 9/8/06, Carl Lerche <carl.lerche at verizon.net> wrote:> Probably a "dumb" question, but what could be considered a good > number of requests / second?That is not easily answered, since performance with any dynamic page rendering tends to be proportional to the size of the page and the amount of it that is generated via code. Kirk Haines
Also, is there any documentation or tutorials out there on the best way to use something like ruby-prof to tune a rails app? I just kind of have been including profiler code to tune various sections and what not that I knew were slower. Most of my applications aren''t incredibly complex so I know that the main points with them are to watch for bad SQL queries and not to instantiate too many objects from these queries. But, when I''m working on a really complex web app, should I launch mongrel with ruby-prof and kind of test the whole thing or should I keep working on tuning specific parts? In short, all my tuning abilities have come from just messing around and using my own logic (for better or worse) as to how I should go about tuning. Are there any resources for me to better improve my ability at tuning apps? Thanks, -carl On Sep 8, 2006, at 5:33 PM, Zed Shaw wrote:> 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.