mirror of
https://github.com/frappe/gunicorn.git
synced 2026-01-14 11:09:11 +08:00
Move tunning parameters to the FAQ.
This commit is contained in:
parent
d8e6cb1769
commit
d26afdacc1
@ -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
|
||||
the optimal number of workers is. Our recommendation is to start with the above
|
||||
guess and tune using TTIN and TTOU signals while the application is under load.</p>
|
||||
<p>Obviously, your particular hardware and application are going to affect the
|
||||
optimal number of workers. Our recommendation is to start with the above guess
|
||||
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>
|
||||
|
||||
@ -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="2048"
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
@ -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
|
||||
the optimal number of workers is. Our recommendation is to start with the above
|
||||
guess and tune using TTIN and TTOU signals while the application is under load.
|
||||
Obviously, your particular hardware and application are going to affect the
|
||||
optimal number of workers. Our recommendation is to start with the above guess
|
||||
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
|
||||
|
||||
@ -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"
|
||||
|
||||
@ -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"
|
||||
Loading…
x
Reference in New Issue
Block a user