How to configure nginx and uWSGI to serve Django projects | Hacker News Reader

How to configure nginx and uWSGI to serve Django projects

blog.eyallupu.com

73 pointsGilK21 comments

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

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.

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.

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

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

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.

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!

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.

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

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

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.

you can directly link uWSGI with varnish using http protocol instead of the uwsgi one: http://projects.unbit.it/uwsgi/wiki/Example#varnish

I did not know that... That's pretty awesome.

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.

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

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.

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)

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.

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.

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.

I have only used apache as an application server with mod wsgi behind nginx. I have not used gunicorn or uwsgi. Yhanks for the correction, I should have just stopped my explanation before that.

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.

Reply on news.ycombinator.com