Although there are many HTTP proxies available, we strongly advise that you use Nginx. If you choose another proxy server you need to make sure that it buffers slow clients. Without this buffering Gunicorn will be easily susceptible to Denial-Of-Service attacks.
+An example configuration file for use with Nginx:
+
+worker_processes 1;
+
+user nobody nogroup;
+pid /tmp/nginx.pid;
+error_log /tmp/nginx.error.log;
+
+events {
+ worker_connections 1024;
+ accept_mutex off;
+}
+
+http {
+ include mime.types;
+ default_type application/octet-stream;
+ access_log /tmp/nginx.access.log combined;
+ sendfile on;
+
+ upstream app_server {
+ server unix:/tmp/gunicorn.sock fail_timeout=0;
+ # For a TCP configuration:
+ # server 192.168.0.7:8000 fail_timeout=0;
+ }
+
+ server {
+ listen 80 default;
+ client_max_body_size 4G;
+ server_name _;
+
+ keepalive_timeout 5;
+
+ # path for static files
+ root /path/to/app/current/public;
+
+ location / {
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ proxy_set_header Host $http_host;
+ proxy_redirect off;
+
+ if (!-f $request_filename) {
+ proxy_pass http://app_server;
+ break;
+ }
+ }
+
+ error_page 500 502 503 504 /500.html;
+ location = /500.html {
+ root /path/to/app/current/public;
+ }
+ }
+}
+
+A popular method for deploying Gunicorn is to have it monitored by runit. An example service definition:
++#!/bin sh + +GUNICORN=/usr/local/bin/gunicorn +ROOT=/path/to/project +PID=/var/run/gunicorn.pid + +APP=main:application + +if [ -f $PID ]; then rm $PID fi + +cd $ROOT +exec $GUNICORN -C $ROOT/gunicorn.conf.py --pidfile=$PID $APP ++
You can gracefully reload by sending HUP signal to gunicorn:
$ kill -HUP masterpid
send TTIN/TTOUT signals to do it:
+To increase the worker count by one:
-$ kill -TTIN masterpid +$ kill -TTIN $masterpid ++
To decrease the worker count by one:
++$ kill -TTOUT $masterpid-
will increase the number from one worker
There are various kernel parameters that you might want to tune in order to deal with a large number of simultaneous connections. Generally these should only affect sites with a large number of concurrent requests and apply to any sort of network server you may be running. They're listed here for ease of reference.
-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.
-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 1024 --
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="1024" --
After a socket is closed it eventually enters the TIME_WAIT state. This can become an issue after a prolonged burst of client activity. Eventually the ephemeral port range is used up 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" --
Gunicorn performances are good enough for most cases. Most often performances can be improved in your application.
+See Configuration for more informations.
-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.
There are various kernel parameters that you might want to tune in order to deal with a large number of simultaneous connections. Generally these should only affect sites with a large number of concurrent requests and apply to any sort of network server you may be running. They're listed here for ease of reference.
+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.
-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 1024 +$ sudo ulimit -n 2048
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="1024" +$ sudo sysctl -w kern.ipc.somaxconn="2048"
After a socket is closed it eventually enters the TIME_WAIT state. This can become an issue after a prolonged burst of client activity. Eventually the ephemeral port range is used up which can cause new connections to stall while they wait for a valid port.
+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" diff --git a/doc/htdocs/tunning.html b/doc/htdocs/tunning.html deleted file mode 100644 index d50f2d26..00000000 --- a/doc/htdocs/tunning.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - -Green Unicorn - Tunning - - - - - - - --- - \ No newline at end of file diff --git a/doc/htdocs/usage.html b/doc/htdocs/usage.html index a46a69e6..a39b771d 100644 --- a/doc/htdocs/usage.html +++ b/doc/htdocs/usage.html @@ -38,6 +38,7 @@- -- - - - -gunicorn
- -- get the source in - git then - send feedback ---- - - - - - -Gunicorn performances are good enough for most cases. Most often performances can be improved in your application.
---Unicorn configuration
-See Configuration for more informations.
--
-- worker_processes should be scaled to the number of processes your backend system(s) can support. DO NOT scale it to the number of external network clients your application expects to be serving. Gunicorn is NOT for serving slow clients, that is the job of nginx.
---Kernel Parameters
-There are various kernel parameters that you might want to tune in order to deal with a large number of simultaneous connections. Generally these should only affect sites with a large number of concurrent requests and apply to any sort of network server you may be running. They're listed here for ease of reference.
-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.
---Increasing the File Descriptor Limit
-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 1024 ----Increasing the 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="1024" ----Widening the Ephemeral Port Range
-After a socket is closed it eventually enters the TIME_WAIT state. This can become an issue after a prolonged burst of client activity. Eventually the ephemeral port range is used up 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" --