Move tunning parameters to the FAQ.

doc/htdocs/design.html

@@ -104,14 +104,17 @@ the servers. For the curious, <a class="reference external" href="http://ha.cker
 </div>
 <div class="section" id="how-many-workers">
 <h2><a class="toc-backref" href="#contents">How Many Workers?</a></h2>
+<p>DO NOT scale the number of workers to the number of clients you expect to have.
+Gunicorn should only need 4-12 worker processes to handle hundreds or thousands
+of requests per second.</p>
 <p>Gunicorn relies on the operating system to provide all of the load balancing
 when handling requests. Generally we recommend <tt class="docutils literal">(2 x $num_cores) + 1</tt> as the
 number of workers to start off with. While not overly scientific, the formula
 is based on the assumption that for a given core, one worker will be reading
 or writing from the socket while the other worker is processing a request.</p>
-<p>Obviously, your particular hardware and application are going to affect what
+<p>Obviously, your particular hardware and application are going to affect the
-the optimal number of workers is. Our recommendation is to start with the above
+optimal number of workers. Our recommendation is to start with the above guess
-guess and tune using TTIN and TTOU signals while the application is under load.</p>
+and tune using TTIN and TTOU signals while the application is under load.</p>
 <p>Always remember, there is such a thing as too many workers. After a point your
 worker processes will start thrashing system resources decreasing the throughput
 of the entire system.</p>

doc/htdocs/faq.html

@@ -47,6 +47,11 @@
 <li><a class="reference internal" href="#how-can-i-change-the-number-of-workers-dynamically" id="id11">How can I change the number of workers dynamically?</a></li>
 </ul>
 </li>
+<li><a class="reference internal" href="#kernel-parameters" id="id12">Kernel Parameters</a><ul>
+<li><a class="reference internal" href="#how-can-i-increase-the-maximum-number-of-file-descriptors" id="id13">How can I increase the maximum number of file descriptors?</a></li>
+<li><a class="reference internal" href="#how-can-i-increase-the-maximum-socket-backlog" id="id14">How can I increase the maximum socket backlog?</a></li>
+</ul>
+</li>
 </ul>
 </div>
 <div class="section" id="wsgi-bits">
@@ -108,6 +113,34 @@ $ kill -TTOU $masterpid
 </blockquote>
 </div>
 </div>
+<div class="section" id="kernel-parameters">
+<h2><a class="toc-backref" href="#questions">Kernel Parameters</a></h2>
+<p>When dealing with large numbers of concurrent connections there are a handful of
+kernel parameters that you might need to adjust. Generally these should only
+affect sites with a very large concurrent load. These parameters are not
+specific to Gunicorn, they would apply to any sort of network server you may be
+running.</p>
+<p>These commands are for Linux. Your particular OS may have slightly different
+parameters.</p>
+<div class="section" id="how-can-i-increase-the-maximum-number-of-file-descriptors">
+<h3><a class="toc-backref" href="#questions">How can I increase the maximum number of file descriptors?</a></h3>
+<p>One of the first settings that usually needs to be bumped is the maximum number
+of open file descriptors for a given process. For the confused out there,
+remember that Unices treat sockets as files.</p>
+<pre class="literal-block">
+$ sudo ulimit -n 2048
+</pre>
+</div>
+<div class="section" id="how-can-i-increase-the-maximum-socket-backlog">
+<h3><a class="toc-backref" href="#questions">How can I increase the maximum socket backlog?</a></h3>
+<p>Listening sockets have an associated queue of incoming connections that are
+waiting to be accepted. If you happen to have a stampede of clients that fill up
+this queue new connections will eventually start getting dropped.</p>
+<pre class="literal-block">
+$ sudo sysctl -w net.core.somaxconn=&quot;2048&quot;
+</pre>
+</div>
+</div>
 </div>
 
       </div>

doc/site/design.rst

@@ -74,15 +74,19 @@ Some examples of behavior requiring asynchronous workers:
 How Many Workers?
 =================
 
+DO NOT scale the number of workers to the number of clients you expect to have.
+Gunicorn should only need 4-12 worker processes to handle hundreds or thousands
+of requests per second.
+
 Gunicorn relies on the operating system to provide all of the load balancing
 when handling requests. Generally we recommend ``(2 x $num_cores) + 1`` as the
 number of workers to start off with. While not overly scientific, the formula
 is based on the assumption that for a given core, one worker will be reading
 or writing from the socket while the other worker is processing a request.
 
-Obviously, your particular hardware and application are going to affect what
+Obviously, your particular hardware and application are going to affect the
-the optimal number of workers is. Our recommendation is to start with the above
+optimal number of workers. Our recommendation is to start with the above guess
-guess and tune using TTIN and TTOU signals while the application is under load.
+and tune using TTIN and TTOU signals while the application is under load.
 
 Always remember, there is such a thing as too many workers. After a point your
 worker processes will start thrashing system resources decreasing the throughput

doc/site/faq.rst

@@ -78,3 +78,36 @@ How can I change the number of workers dynamically?
 .. _worker_class: /configure.html#worker-class
 .. _`number of workers`: /design.html#how-many-workers
 
+Kernel Parameters
+=================
+
+When dealing with large numbers of concurrent connections there are a handful of
+kernel parameters that you might need to adjust. Generally these should only
+affect sites with a very large concurrent load. These parameters are not
+specific to Gunicorn, they would apply to any sort of network server you may be
+running.
+
+These commands are for Linux. Your particular OS may have slightly different
+parameters.
+
+How can I increase the maximum number of file descriptors?
+----------------------------------------------------------
+
+One of the first settings that usually needs to be bumped is the maximum number
+of open file descriptors for a given process. For the confused out there,
+remember that Unices treat sockets as files.
+
+::
+    
+    $ sudo ulimit -n 2048
+
+How can I increase the maximum socket backlog?
+----------------------------------------------
+
+Listening sockets have an associated queue of incoming connections that are
+waiting to be accepted. If you happen to have a stampede of clients that fill up
+this queue new connections will eventually start getting dropped.
+
+::
+
+    $ sudo sysctl -w net.core.somaxconn="2048"

doc/site/tuning.rst

@@ -1,68 +0,0 @@
-template: doc.html
-title: Tuning
-
-Tuning
-======
-
-Unicorn Configuration
----------------------
-
-DO NOT scale the number of workers to the number of clients you expect to have.
-Gunicorn should only need 4-12 worker processes to handle hundreds or thousands
-of simultaneous clients. Remember, Gunicorn is **NOT** designed for serving slow
-clients, that's the job of Nginx_.
-
-See Configuration_ for a more thorough description of the available parameters.
-
-.. _Nginx: http://www.nginx.org
-.. _Configuration: configuration.html
-
-Kernel Parameters
------------------
-
-When dealing with large numbers of concurrent connections there are a handful of
-kernel parameters that you might need to adjust. Generally these should only
-affect sites with a very large concurrent load. These parameters are not
-specific to Gunicorn, they would apply to any sort of network server you may be
-running.
-
-The commands listed are tested under Mac OS X 10.6. Your flavor of Unix may use
-slightly different flags. Always reference the appropriate man pages if
-uncertain.
-
-File Descriptor Limits
-++++++++++++++++++++++
-
-One of the first settings that usually needs to be bumped is the maximum number
-of open file descriptors for a given process. For the confused out there,
-remember that Unices treat sockets as files.
-
-::
-    
-    $ sudo ulimit -n 2048
-
-Listen Queue Size
-+++++++++++++++++
-
-Listening sockets have an associated queue of incoming connections that are
-waiting to be accepted. If you happen to have a stampede of clients that fill up
-this queue new connections will eventually start getting dropped.
-
-::
-
-    $ sudo sysctl -w kern.ipc.somaxconn="2048"
-
-Ephemeral Port Range
-++++++++++++++++++++
-
-After a socket is closed it enters the TIME_WAIT state. This can become an issue
-after a prolonged burst of client activity. Eventually the ephemeral port range
-is exhausted which can cause new connections to stall while they wait for a
-valid port.
-
-This setting is generally only required on machines that are being used to test
-a network server.
-
-::
-
-    $ sudo sysctl -w net.inet.ip.portrange.first="8048"