

How to configure nginx and uWSGI to serve Django projects - GilK
http://blog.eyallupu.com/2012/01/how-to-configure-nginx-and-uwsgi-to.html
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...](http://stackoverflow.com/questions/3937224/differences-and-uses-
between-wsgi-cgi-fastcgi-and-mod-python-in-regards-to-py)

------
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...](http://brandonkonkle.com/blog/2010/sep/14/django-uwsgi-and-nginx/))

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.

~~~
JonAtkinson
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!

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

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

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

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

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

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

