1 files changed, 90 insertions, 0 deletions
diff --git a/site/src/docs/how_many_mongrels.page b/site/src/docs/how_many_mongrels.page
new file mode 100644
index 0000000..7911293
--- /dev/null
+++ b/site/src/docs/how_many_mongrels.page
@@ -0,0 +1,90 @@
+---
+title: Tuning
+inMenu: true
+directoryName: Tuning
+---
+
+h1.  How Many Mongrel Instances Should I Run?
+
+There is no set number that is "best" since that depends on factors like the
+type of application, server hardware, how dynamic the appication is, etc.
+
+I've found that 8-12 mongrel processes per CPU is about right, but I determined
+this by starting with 1 and then doing the following:
+
+h2. Baseline Your Server
+
+Pick a URL to a small file that is running on your apache server and is not
+served by Mongrel at all.  This URL will be your "best possible baseline".
+
+Build your baseline measurement first.  Using httperf, measure the speed of
+your URL so that you know how fast you could possibly get if you served
+everything static in ideal situations.
+
+**Make sure you do this on a different machine over an ideal network.** 
+Not your damn wifi over a phone line through sixteen poorly configured routers.
+Right next to the box your testing with a fast switch and only one hop is the
+best test situation.  This removes network latency from your test as a
+confounding factor.
+
+
+h2. Baseline Rails and Mongrel
+
+Pick a page that's a good representative page for your application.  Make sure
+you disable logins to make this test easier to run.  Hit this Rails page and
+compare it to your baseline page.
+
+* If your rails measurement is *faster* than your baseline
+  measurement then you screwed up.  Rails shouldn't be faster than a file
+  off your static server.  Check your config.
+* If your rails measurement is *horribly slow* compared to baseline
+  then you've got some config to do before you even start tuning the
+  number of process.  Repeat this test until one mongrel is as fast as
+  possible.
+
+h2. Tweak
+
+Once you've got a Rails page going at a reasonable speed, then you'll want to
+increase the --rate setting to make sure that it can handle the reported rate.
+
+Finally, alternate between adding a mongrel process and running the test with
+the next highest rate you'd get.  Stop when adding one more server doesn't
+improve your rate.
+
+*Make sure you run one round of the test to get the server "warmed up", and
+then run the real one.*  Heck, run like 5 or 6 just to make sure you're not
+getting a possibly bad reading.
+
+h2. Example
+
+# Run the test and find out that one mongrel can support a @--rate@ of 120 req/second.
+# Add another mongrel and run the test again with @--rate@ 240.  It handles this
+  just find so you add another and get @--rate@ 360.
+# Try another one and it dies.  Giving @--rate@ 480 gets you only a rate of 100.
+  Your server has hit it's max and broke.  
+# Try tuning the @--rate@ down at this and see if it's totally busted (like, 4 mongrels 
+  only gets you @--rate@ 380) or if it's pretty close to 480.
+# That should do it.  A good practice is to also look at the CPUs on the
+  server with top and see what kind of thrashing you give the server.
+
+
+h2. HTTPERF
+
+Here's the commands I use for each test, but read the man page for
+httperf so that you learn to use it.  It's an important tool and just
+cut-pasting what I have here is not going to do it for you.
+
+* @httperf --server www.theserver.com --port 80 --uri /tested --num-conns <10 second count>@
+
+* @httperf --server www.theserver.com --port 80 --uri /tested --num-conns <10 second count> --rate <reported req/sec>@
+
+Where @<10 second count>@ is enough connections to make the test run for 10
+seconds.  Start off with like 100 and keep raising it until it goes for 10
+seconds.
+
+Where @<reported req/sec>@ is whatever httperf said the estimated
+requests/second were.  What you're doing here is seeing if it really can handle
+that much concurrency.  Try raising it up and dropping it down to see the
+impact of performance on higher loads.
+
+Have fun.