django WSGI & limmiting connections
manlio_perillo at libero.it
Thu May 22 14:54:07 MSD 2008
Almir Karic ha scritto:
> i have two question, first relates to running django under nginx as
> WSGI app, i can't seem to find any docs about it. right now i'm
> running django apps as FCGI processes and have (ugly) shell script who
> makes sure the FCGI processes are alive and restarts them when people
> update the code, i am hopping to get rid of this ugly script by
> introducing WSGI in my setup so that nginx alone can handle spawning
> of whatever_wsgi_requires to serve the page correctly, is this
> possible? any examples? (i can't seem to relate things in examples/ to
> django :-() also i would like that every app runs as it's own user, is
> this what wsgi_enable_subinterpreters is meant for?
The WSGI module will execute your WSGI application *embedded* in Nginx.
This *may not* be the best solution, since Nginx only spawns a *fixed*
number of worker processes.
I suggest you to do some tests, using the Apache mod_wsgi implementation
as a comparison (note that the Apache implementation has a lot of
Currently there are no specific examples on how to execute a Django
application, but you can check the Apache mod_wsgi wiki page:
to see how to expose a WSGI conforming application from Django.
As for executing each app as a different user, this is not possible.
With `wsgi_enable_subinterpreters`, Nginx simply will excutes each
application in a separate Python interpreter (and this is absolutely
required for Django since it uses a global state, so you can't execute
more then one application per "python process").
Before using the WSGI module for Nginx, *please* make sure you
understand the differences between this module and the Apache WSGI module.
A "suggested" deployment is:
1) a master Nginx instance, that will proxy requests for other servers
and will serve static images
2) a Nginx instance for each of the Django application, executed as the
Note that you should probabily set worker_processes to the number of
available CPU cores.
This means that, assuming you have a 4 core CPU, you will have:
N + 4 * N active processes (excluding the master Nginx instance), where
N is the number of your Django applications.
This number of processes is fixed, so it can be either *more* than
required, or *less* than required.
With Apache you have a lot more options.
You can execute the applications embedded in Apache (and let Apache
choose the number of workers, both process worker or thread worker).
Moreover you can choose to executes your application in daemon mode (but
still managed by Apache).
I will probabily never implement these features for Nginx, since they
will make the implementation a lot more hard to write, and there is
already Apache if you want this.
Which implementation is better is hard to say, it depends on the
One last thing: when the WSGI application code is updated, you can send
an HUP signal to Nginx master process.
You can also set:
and have each worker automatically restarted when the main application
script is updated, but this has some minor "problems" (explained in the
NOTE that with the current implementation, the Python interpreter is not
fully restarted when you send the HUP signal to Nginx master process
(more details in the BUGS file).
Regards Manlio Perillo
More information about the nginx