Chapter 9Gunicorn uses the pre-fork process model described earlier. You can set the number
of processes (Gunicorn calls them workers) using the -w command line option.
The 'Design' section of the documentation contains details on determining the best
number of workers to use, though a good place to start is (2 x $num_cores) + 1,
where $num_cores is the number of CPU cores available to Gunicorn.
Gunicorn offers two standard worker types: sync and async. The sync type provides
strictly one-worker-per-client-connection behavior, the async type uses eventlet
(see Chapter 8, Client and Server Applications, for details and installation instructions
for this library) to provide an event-based worker, which can handle multiple
connections. The sync type is only recommended if you are using Gunicorn behind
a reverse proxy (see below), as using the sync type to serve directly to the Internet
leaves your application vulnerable to Denial of Service attacks (see the Design
section of the documentation for more details). If you are not using a reverse proxy,
the async type should be used instead. The worker type is set on the command line
using the -k option.
One effective way to improve performance and scale further is to employ a fast,
event-driven web server, such as nginx, as a reverse proxy in front of your Gunicorn
instance. A reverse proxy acts as a first line server for incoming web requests. It
directly responds to any requests it can determine are erroneous, and can also be
configured to serve static content in place of our Gunicorn instance. However, it
is also configured to forward any requests that do require dynamic content to our
Gunicorn instance so our Python web application can handle them. In this way, we
get the performance benefits of nginx to deal with the bulk of our web traffic, and
Gunicorn and our web application can focus on delivering just the dynamic pages.
Detailed instructions on configuring this reverse proxy configuration
can be found on the Gunicorn pages at http://gunicorn-
docs.readthedocs.org/en/latest/deploy.html#nginx-
configuration.If you're more comfortable with Apache, then another effective hosting method
is Apache with the mod_wsgi module. This takes a little more configuring, and
full instructions can be found at: https://code.google.com/p/modwsgi/.
mod_wsgi defaults to running applications in embedded mode, where the web
application is hosted in each Apache process, and which results in a setup like the
preceding pre-forking example. Alternatively it provides a daemon mode, where
mod_wsgi manages a pool of processes external to Apache, similar to the earlier
FastCGI example. Daemon mode is in fact recommended for stability and memory
performance. See the mod_wsgi quick configuration documentation for instructions
on this configuration, it can be found at: https://code.google.com/p/modwsgi/
wiki/QuickConfigurationGuide.