Django WSGI & limmiting connections

Server NGINX
1

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?

my second question is related to protecting apache from web crawlers
(when they crawl the main site the entire server struggles). since i
already have nginx infront of apache i’m thinking on using it to
protect it as well :-). i’m thinking the ‘‘optimal’’ way to do it is
to make sure that no more than X times per Y ammount of time clients
can connect to apache, is there a way to achieve that (as far as i
read on wiki limit_conn can only make sure that no more than X
concurrent connections are accepted from a single ip)? is there any
better way to do this kind of thing?

2

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