

Django Setup using Nginx and Gunicorn - senko
http://senko.net/en/django-nginx-gunicorn/

======
uggedal
Or you could use my Puppet modules which handles this for you on Debian or
Ubuntu, using Monit in stead of supervisord:
[http://journal.uggedal.com/deploying-wsgi-applications-
with-...](http://journal.uggedal.com/deploying-wsgi-applications-with-puppet/)

------
adambard
I'm a fan of uWSGI, personally. If anyone's interested, I wrote up (before it
was cool) a guide to Django/nginx/uwsgi in more or less the same format:

[http://posterous.adambard.com/start-to-finish-serving-
mysql-...](http://posterous.adambard.com/start-to-finish-serving-mysql-backed-
django-w)

------
not_chriscohoat
Not a bad how-to...he mentioned the mod_wsgi route and that's the one I'm most
fond of. You can still use Nginx to handle all static files and proxy all
other requests to Django.

A tutorial link if you're interested:
[http://www.meppum.com/2009/jan/17/installing-django-
ubuntu-i...](http://www.meppum.com/2009/jan/17/installing-django-ubuntu-
intrepid/)

------
brendoncrawford
_> The best seem to be Gunicorn and uWSGI, and Gunicorn seems the best
supported and most active project._

This is not so cut and dry. In May, Gunicorn had 12 mailing list messages,
where uWsgi had 191. uWsgi has a twitter with 225 followers, where Gunicorn
has none. #gunicorn@freenode has 32 users, but #nginx@freenode seems to have a
lot of uWsgi users.

Also, the author mentions nothing about installing the Nginx PPA for ubuntu.
If you use the default repo on Lucid (as suggested by the author), you will
end up with a very old version of Nginx that doesn't even natively support
wsgi.

~~~
senko
> _If you use the default repo on Lucid (as suggested by the author), you will
> end up with a very old version of Nginx that doesn't even natively support
> wsgi._

Nginx+Gunicorn combination uses HTTP, so WSGI support is not needed in that
case.

~~~
unbit
uWSGI supports HTTP and FastCGI too, natively. Using the uwsgi protocol (that
has nothing to do with WSGI standard) is only a way to increase performance
and add a bunch of features. uWSGI and gunicorn are very different projects,
with very, very different targets. Trying to make a fair comparison is
impossibile.

------
simonw
I'm not clear on the advantages of using nginx+Gunicorn over nginx+proxy-to-
Apache/mod_wsgi

~~~
timc3
Its not really hip and trendy, its the standard way to go now days. The
advantages to me are, Nginx is much lighter on resources for any given number
of concurrent connections. I can keep those connections open if I really need
to, and I have found it flexible enough for almost all scenarios (hosting SVN
is the one thing I can think of that it doesn't do, but SVN's days are
numbered for my usage anyway and http1.1 proxying backends).

Nginx's syntax for its configuration tends to be easy to read, the community
is helpful. Its also well tested and hosting a decent percentage of websites.

I question the need to use Apache2 these days and anyone who blindly
recommends it without knowing the alternatives as they tend to be uninformed
about modern hosting environments.

~~~
simonw
That's why I run Apache+mod_wsgi behind an nginx proxy (and have nginx serve
up static files etc directly).

------
Pewpewarrows
This is pretty much my exact setup when rolling a custom server, sans-Upstart
(I prefer supervisord just because it's what I'm used to).

------
ehutch79
Am I the only one who's never had gunicorn crash on him? I don't run
supervisor or anything, but I've never had any issues either.

~~~
senko
I run supervisor to be able to restart servers at will. I've never had
gunicorn crash at me.

~~~
ehutch79
isn't that want init.d scripts are for?

~~~
senko
You could also write those, yeah. I mentioned Upstart, which is a replacement
for init.d scripts in Ubuntu. There's also djb's daemontools, and a couple of
other ways to do it.

------
megaman821
Everyone always shows a single server setup. What if you have a dozen sites?
You can't just give each one 9 processes, you will swamp your box. Is there
any way to do a master setup where you can dynamically feed it your settings
file?

~~~
Stiffy
If you're already running a dozen sites on one server, collectively they're
probably not getting very much traffic. You may very well be able to use a
large number of processes just fine.

~~~
megaman821
That is probably true CPU wise, I am just worried about memory. If each
process is 50 MB and you have 12 servers and 9 processes per, that is over 5
GB. If my machine only has 4 GB of RAM some of those processes must be in the
swap file.

~~~
unshift
you can do pretty well with 1-2 processes per site; if you don't have the
traffic to warrant it, there's no reason to run more. gunicorn can also use an
async worker type (gevent) which can help keep the number of needed processes
down.

django also has a sites package, so you can run multiple sites per django
instance. it's less encapsulated but if you run a high number of websites with
a low amount of traffic each it makes a lot of sense.

------
chopsueyar
Thank you!

