How to configure nginx and uWSGI to serve Django projects

http://blog.eyallupu.com/2012/01/how-to-configure-nginx-and-uwsgi-to.html

by GilK • 15 years ago

73 21 15 years ago

blog.eyallupu.com

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

wulczer• 15 years ago

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.

niyazpk• 15 years ago

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• 15 years ago

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

unbit4• 15 years ago

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.

JonAtkinson• 15 years ago

I've followed uWSGI development on and off for a little while, but I never knew about Emperor. I've been looking for something similar for a while. Thanks a lot for your work!

timc3• 15 years ago

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.

thomaslangston• 15 years ago

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.

Ixiaus2• 15 years ago

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

gardentheory3• 15 years ago

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

mrweasel2• 15 years ago

Varnish is just a proxy, or webcache, as I believe they like to call it. Nginx is needed because Varnish won't talk directly to the uwsgi processes, Varnish only understands http. The data that Varnish need to cache has to be supplied by a webserver somewhere and nginx is pretty nice and easily configurable. So I would assume that the idea is to use nginx as the webserver, not the cache/proxy.

acdha• 15 years ago

nginx is a much weaker proxy and doesn't allow as much customization as Varnish does. A coworker also ran into some basic HTTP compliance issues with nginx's cache and Vary headers - IIRC it simply ignores them outright. If you need more than very basic caching it's usually better to use Varnish because it's obsessively focused on doing that job well.

Depending on how you choose to implement it, this may also result in cleaner architecture if you have Varnish as a simple HTTP brick with little knowledge of the backend implementation, leaving all of the gory details to nginx.

Ixiaus2• 15 years ago

I basically use nginx the way people would use Apache and Varnish I use as a webcache. Others have explained it thoroughly.

ColdAsIce• 15 years ago

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.

gardentheory3• 15 years ago

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.

unbit4• 15 years ago

No, uWSGI has nothing to do with performance. Its strength is in the features and operational modes. Each application is diferent from the others and (could) requires specific tuning. This is the spirit of the project, that is at the opposite of solutions like gunicorn. There is no "best choice", it depends on how you approach to system administration/development. Saying uWSGI is better than gunicorn (or the opposite) is like comparing bananas with oranges.

unbit4• 15 years ago

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.

prodigal_erik• 15 years ago

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• 15 years ago

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)

How to configure nginx and uWSGI to serve Django projects

Related Stories