django WSGI & limmiting connections

[Manlio Perillo]

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 
configuration options).


Currently there are no specific examples on how to execute a Django 
application, but you can check the Apache mod_wsgi wiki page:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

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
    given user.

    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 
application.



One last thing: when the WSGI application code is updated, you can send 
an HUP signal to Nginx master process.

You can also set:
   wsgi_script_reloading on:
   wsgi_reload_mechanism process;

and have each worker automatically restarted when the main application 
script is updated, but this has some minor "problems" (explained in the 
README file).


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