Almir K. ha scritto:
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.
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
A “suggested” deployment is:
a master Nginx instance, that will proxy requests for other servers
and will serve static images
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 P.