Zed, thanks very much for this detailed description. One question to 2.a) if no real server just one hop away from the entry-web-server (or loadbalancer) is available (e.g.: just having rented one dedicated server) , what is the best alternative:
<br><br>1) run httperf on the same machine as the webserver<br>2) run httperf on the same machine as the webserver but on its own XEN virtual machine.<br>3) run httperf from development machine over DSL connection<br><br>
regards<br>Roberto<br><br><div><span class="gmail_quote">On 5/10/06, <b class="gmail_sendername">Zed Shaw</b> <<a href="mailto:zedshaw@zedshaw.com">zedshaw@zedshaw.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 2006-05-10 at 16:15 -0400, Adam Denenberg wrote:<br>> is there a way to determine how best to determine the number of<br>> mongrel processes to start? Right now i am running 2 in production<br>> but I see some people run about 8 or so. What is the cutoff and
<br>> determening factor for this ?<br><br>There is no set number that is "best" since that depends on factors like<br>the type of application, hardware you run on, how dynamic the appication<br>is, etc.<br><br>
I've found that 8-12 mongrel processes per CPU does right, but I<br>determined this by starting with 1 and then doing the following:<br><br>1) You'll need a URL to a small file that is running on your apache<br>server and is not served by Mongrel at all. This URL will be your "best
<br>possible baseline".<br><br>2) Build your baseline measurement first. Using httperf, measure the<br>speed of your URL from #1 above so that you know how fast you could<br>possibly get if you served everything static in ideal situations.
<br><br> a) ***** Make sure you do this on a different machine over an ideal<br>network. Not your damn wifi over a phone line through sixteen poorly<br>configured routers. Right next to the box your testing with a fast<br>
switch and only one hop is the best test situation. This removes<br>network latency from your test as a confounding factor.*****<br><br>3) Pick a page that's a good representative page for your application.<br>Make sure you disable logins to make this test easier to run. Hit this
<br>Rails page and compare it to your baseline page.<br><br> a) If your *rails* measurement is FASTER than your baseline<br>measurement then you screwed up. Rails shouldn't be faster than a file<br>off your static server. Check your config.
<br><br> b) If your rails measurement is horribly slow compared to baseline<br>then you've got some config to do before you even start tuning the<br>number of process. Repeat this test until one mongrel is as fast as<br>
possible.<br><br>4) Once you've got a Rails page going at a reasonable speed, then you'll<br>want to increase the --rate setting to make sure that it can handle the<br>reported rate.<br><br>5) Finally, you alternate between adding a mongrel process and running
<br>test #4 with the next highest rate you'd get. You basically stop when<br>adding one more server doesn't improve your rate.<br><br> a) Make sure you run one round of test #4 to get the server "warmed<br>up", and then run the real one. Hell, run like 5 or 6 just to make sure
<br>you're not getting a possibly bad reading.<br><br> b) Example, you run #4 and find out the --rate one mongrel can support<br>is 120 req/second. You add another mongrel and run the test again with<br>--rate 240. It handles this just find so you add another and get --rate
<br>360. Ok, try another one and you get it dies. Giving --rate 480 gets<br>you only a rate of 100. Your server has hit it's max and broke. Try<br>tuning the --rate down at this and see if it's totally busted (like, 4
<br>mongrels only gets you --rate 380) or if it's pretty close to 480.<br><br><br>That should do it. A good practice is to also look at the CPUs on the<br>server with top and see what kind of thrashing you give the server.
<br><br>HTTPERF<br><br>Here's the commands I use for each test, but read the man page for<br>httperf so that you learn to use it. It's an important tool and just<br>cut-pasting what I have here is not going to do it for you.
<br><br>#2 && #3) httperf --server <a href="http://www.theserver.com">www.theserver.com</a> --port 80 --uri /tested<br>--num-conns <10 second count><br><br>#4) httperf --server <a href="http://www.theserver.com">
www.theserver.com</a> --port 80 --uri /tested<br>--num-conns <10 second count> --rate <reported req/sec><br><br>Where <10 second count> is you put enough connections to make the test<br>run for 10 seconds. Start off with like 100 and keep raising it until
<br>it goes for 10 seconds.<br><br>Where <reported req/sec> is you put in whatever httperf said the<br>estimated requests/second were from #3. What you're doing here is<br>seeing if it really can handle that much concurrency. Try raising it up
<br>and dropping it down to see the impact of performance on higher loads.<br><br>Have fun.<br><br><br><br>--<br>Zed A. Shaw<br><a href="http://www.zedshaw.com/">http://www.zedshaw.com/</a><br><a href="http://mongrel.rubyforge.org/">
http://mongrel.rubyforge.org/</a><br><br><br>_______________________________________________<br>Mongrel-users mailing list<br><a href="mailto:Mongrel-users@rubyforge.org">Mongrel-users@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/mongrel-users">
http://rubyforge.org/mailman/listinfo/mongrel-users</a><br></blockquote></div><br><br clear="all"><br>-- <br>Roberto Saccon