How to configure nginx and uWSGI to serve Django projects

[GilK]

A quick step-by-step guide on how to configure nginx and uWSGI to serve Django projects

[wulczer]

We found that Debian-packaged uWSGI is missing one param in uwsgi_params so you should use this instead:

    location / {
        uwsgi_pass <xxx>;
        include uwsgi_params;
        uwsgi_param UWSGI_SCHEME $scheme;
    }

Without the UWSGI_SCHEME part, Django's Request.get_absolute_uri will return URIs starting with 'http' even if your site is served over HTTPS.

[timc3]

How many more of these tutorials do we actually need? It doesn't actually go into any real detail on what is happening for someone new to trying to bring up a dev box, and it certainly doesn't help those of us more experienced.

What about setting up logging, email, exception emails, time zone, https - things that are actually important for those that haven't done installations much.

[niyazpk]

If anyone (like me) is confused about the differences between WSGI, FCGI, CGI etc., this might be helpful: http://stackoverflow.com/questions/3937224/differences-and-u...

[BonoboBoner]

A good addition would be to use supervisord for running the uwsgi process at system startup. (as described here: http://brandonkonkle.com/blog/2010/sep/14/django-uwsgi-and-n...)

For a good comparison on different WSGI servers (aka uwsgi vs gunicorn, etc):

http://nichol.as/benchmark-of-python-web-servers

[unbit]

supervisor is great, but if you want to host multiple applications the best way would be the uWSGI Emperor http://projects.unbit.it/uwsgi/wiki/Emperor

Regarding the benchmark, it is a bit outdated and the apache+mod_wsgi analysys/configuration is totally wrong (i am one of the uWSGI authors, but mod_wsgi is great, and seeing it blasted wrongly in that url is a bit disappointing)

By the way, do not choose your application server looking only at performance.really.

[thomaslangston]

If you're going to host a tutorial on the web, use some hyperlinks to define your terms. If I hadn't gone to a Django talk last night I'd have no idea what uWSGI and nginx were.

[Ixiaus]

nginx, Varnish, and uWSGI are oh so awesome together. My app (I run a Pyramid based application) is lightning fast, and very easy to configure (much easier than mod_wsgi).

[gardentheory]

Why nginx AND varnish? I thought varnish could proxy as well? Or maybe could you explain your setup.

[prodigal_erik]

WSGI supports native in-proc middleware for stuff like caching, but instead the author is accepting extra process boundaries between the HTTP stack and the remainder of their applications. I've never understood why I'm supposed to prefer that, so I would have liked to see a rationale.

[lza]

Server configs like this is premature optimization IMO. I mean when you get millions of hits and the server slows down sure go for it, but in most cases apache2 with mod_wsgi does the work nicely with practically no config(beside the vhost file)

[ColdAsIce]

Why the need for these "how to configure" this and that when it can be as simple as runthisnowdamnit.py using gunicorn or cherrypy? Or you know, some other server which doesnt require learning and blogging about its configuration and various options it can be set up? Sure that might come in handy, when or rather if you ever face millions of users/load problems.

Wasnt the point of a web application framework that you could put it anywhere and type run and have it done, instead of having to think of process- or event- or thread- based serving and static files? Thats not python. Even php is simpler/better in this regard.

Its not so difficult to run an instance of a threaded/process/eventlet server and let your app do the work.

[gardentheory]

Well i think the gist is that serving files and running applications have different resource requirements. Therefore it is common to have a proxy serve statics and proxy in addition to an application server running python. The advantage with uwsgi as i understand it is that the proxy protocol is faster than http.

[unbit]

in both gunicorn and php you have to choose the number of workers/processes. Most of the time (unless you use php-fastcgi) the number of php processes is choosen by the sysadmin as it maps 1:1 with apache processes. The same is true for mod_wsgi. There is always some form of configuration independently by the load. One of the reasons for some users blaming at apache+mod_wsgi is because they maintain the default (bloated) apache configuration like php users/sysadmin tend to do.