5 ms·

Django Setup using Nginx and Gunicorn

104 points by senko 15y ago

not_chriscohoat 15y ago
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-intrepid/ http://www.meppum.com/2009/jan/17/installing-django-ubuntu-i...
chopsueyar 15y ago
Thank you!
simonw 15y ago
I'm not clear on the advantages of using nginx+Gunicorn over nginx+proxy-to-Apache/mod_wsgi
- Pewpewarrows 15y ago
  In reality, not that much. There's a pretty detailed benchmark breakdown here [1]. From my experience, the point where you see the different methods start to diverge is past the point you're going to be able to handle on a single box with a real-world application anyway. I find that gunicorn is slightly easier to setup (not requiring Apache to be installed, etc), so I've stuck with it. To each their own! [1] http://nichol.as/benchmark-of-python-web-servers http://nichol.as/benchmark-of-python-web-servers
- Stiffy 15y ago
  It's hipper. More trendy. Lets you write blog articles that make it sound like you're cutting-edge.
- senko 15y ago
  A lot of people use apache+nginx+mod_wsgi combination, but it seems to me that's more complicated than having just one web server. Apache might be more versatile, but if used with wsgi, and if you use nginx as well anyways, I don't see the need for all the bells and whistles apache has?
  - Stiffy 15y ago
    Apache is also very well-tested and extremely reliable. For some people and organizations, that's a very important factor.
    - 18pfsmt 15y ago
      I happen to find this post very helpful as a student of the craft, and your comments seem to be defensive of a traditional approach because you don't care to examine the reasons for the choices you've made. The pros and cons of either choice would be more helpful than demonstrating animosity toward an approach you've chosen to dismiss. It's great that you have a setup you know and are comfortable with, but for those of us that would like to explore all options these posts are very helpful. It sucks you have to dismiss this as a ploy to be "hip".
      - ryanhuff 15y ago
        I didnt find the parent defensive. I appears to be more of an observation. Perhaps it was edited after the fact?
        Stiffy 15y ago
        It wasn't edited. I'm not sure why 18pfsmt is overly sensitive. Maybe he subconsciously feels that his new techniques are inferior to proven approaches, and exhibits this through outrage?
- slig 15y ago
  Less packages to keep updated, thus less maintenance.
  - Stiffy 15y ago
    The number of packages involved is a very poor measure of the effort needed to maintain a system. Apache and more established technologies have had much more testing and are far more mature. Their releases are often much more infrequent, merely because most of the problems have already been worked out. Newer technologies, on the other hand, aren't in such a position. Although your solution may involve a smaller number of packages, having to perform weekly or even monthly updates due to the immaturity of the software is much riskier and disruptive than having to upgrade Apache and a few of its modules once or twice a year.
    - slig 15y ago
      Excellent points. Thanks!
- timc3 15y ago
  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 15y ago
    That's why I run Apache+mod_wsgi behind an nginx proxy (and have nginx serve up static files etc directly).
- frankwiles 15y ago
  Simon, slightly better memory usage in most cases. More so if you don't end up stripping out all of the Apache modules you aren't using. But it's such a small differences it usually isn't worth changing from what you know and are comfortable with.
Pewpewarrows 15y ago
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).
megaman821 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
- ehutch79 15y ago
  it's pretty easy to add multiple upstream servers to nginx. If you're at that point you want to be reading the docs and understanding what's going on anyway. Also gunicorn wants n+1 workers, where n is the number of cores you want to devote to it. It's in the docs. So an 8 core machine would want 9 workers. If you've got multi server scaling issues, cut and paste won't help you.
  - 15y ago
ehutch79 15y ago
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 15y ago
  I run supervisor to be able to restart servers at will. I've never had gunicorn crash at me.
  - ehutch79 15y ago
    isn't that want init.d scripts are for?
    - senko 15y ago
      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.
- davisp 15y ago
  If you have Gunicorn crash please make sure and report any tracebacks in the logs to the issue tracker so we know that's something is broken. https://github.com/benoitc/gunicorn/issues https://github.com/benoitc/gunicorn/issues
uggedal 15y ago
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-puppet/ http://journal.uggedal.com/deploying-wsgi-applications-with-...
adambard 15y ago
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-backed-django-w http://posterous.adambard.com/start-to-finish-serving-mysql-...
brendoncrawford 15y ago
> 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.
- davisp 15y ago
  As you say, its not so cut and dry. Gunicorn has only had a mailing list since about May. Most of our dev work is based in IRC or via the GitHub issues tracker. The three committers, @benoitc, @tilgovi, and @davisp have a combined 1709 twitter followers. There are also 479 watchers and 64 forks of the main development repo on GitHub. Bottom line, numbers like this don't really mean much. In the end, people should investigate any project they think is a candidate and make a decision based on their specific criteria rather than try and use some proxy metric to make the decision.
- senko 15y ago
  > 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 15y ago
    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.

104 points by senko 15y ago

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-intrepid/ http://www.meppum.com/2009/jan/17/installing-django-ubuntu-i...

chopsueyar 15y ago

Thank you!

simonw 15y ago

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

Pewpewarrows 15y ago
In reality, not that much. There's a pretty detailed benchmark breakdown here [1]. From my experience, the point where you see the different methods start to diverge is past the point you're going to be able to handle on a single box with a real-world application anyway. I find that gunicorn is slightly easier to setup (not requiring Apache to be installed, etc), so I've stuck with it. To each their own! [1] http://nichol.as/benchmark-of-python-web-servers http://nichol.as/benchmark-of-python-web-servers
Stiffy 15y ago
It's hipper. More trendy. Lets you write blog articles that make it sound like you're cutting-edge.
senko 15y ago
A lot of people use apache+nginx+mod_wsgi combination, but it seems to me that's more complicated than having just one web server. Apache might be more versatile, but if used with wsgi, and if you use nginx as well anyways, I don't see the need for all the bells and whistles apache has?
- Stiffy 15y ago
  Apache is also very well-tested and extremely reliable. For some people and organizations, that's a very important factor.
  - 18pfsmt 15y ago
    I happen to find this post very helpful as a student of the craft, and your comments seem to be defensive of a traditional approach because you don't care to examine the reasons for the choices you've made. The pros and cons of either choice would be more helpful than demonstrating animosity toward an approach you've chosen to dismiss. It's great that you have a setup you know and are comfortable with, but for those of us that would like to explore all options these posts are very helpful. It sucks you have to dismiss this as a ploy to be "hip".
    - ryanhuff 15y ago
      I didnt find the parent defensive. I appears to be more of an observation. Perhaps it was edited after the fact?
      - Stiffy 15y ago
        It wasn't edited. I'm not sure why 18pfsmt is overly sensitive. Maybe he subconsciously feels that his new techniques are inferior to proven approaches, and exhibits this through outrage?
slig 15y ago
Less packages to keep updated, thus less maintenance.
- Stiffy 15y ago
  The number of packages involved is a very poor measure of the effort needed to maintain a system. Apache and more established technologies have had much more testing and are far more mature. Their releases are often much more infrequent, merely because most of the problems have already been worked out. Newer technologies, on the other hand, aren't in such a position. Although your solution may involve a smaller number of packages, having to perform weekly or even monthly updates due to the immaturity of the software is much riskier and disruptive than having to upgrade Apache and a few of its modules once or twice a year.
  - slig 15y ago
    Excellent points. Thanks!
timc3 15y ago
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 15y ago
  That's why I run Apache+mod_wsgi behind an nginx proxy (and have nginx serve up static files etc directly).
frankwiles 15y ago
Simon, slightly better memory usage in most cases. More so if you don't end up stripping out all of the Apache modules you aren't using. But it's such a small differences it usually isn't worth changing from what you know and are comfortable with.

Pewpewarrows 15y ago

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

megaman821 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.
ehutch79 15y ago
it's pretty easy to add multiple upstream servers to nginx. If you're at that point you want to be reading the docs and understanding what's going on anyway. Also gunicorn wants n+1 workers, where n is the number of cores you want to devote to it. It's in the docs. So an 8 core machine would want 9 workers. If you've got multi server scaling issues, cut and paste won't help you.
- 15y ago

ehutch79 15y ago

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 15y ago
I run supervisor to be able to restart servers at will. I've never had gunicorn crash at me.
- ehutch79 15y ago
  isn't that want init.d scripts are for?
  - senko 15y ago
    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.
davisp 15y ago
If you have Gunicorn crash please make sure and report any tracebacks in the logs to the issue tracker so we know that's something is broken. https://github.com/benoitc/gunicorn/issues https://github.com/benoitc/gunicorn/issues

uggedal 15y ago

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-puppet/ http://journal.uggedal.com/deploying-wsgi-applications-with-...

adambard 15y ago

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-backed-django-w http://posterous.adambard.com/start-to-finish-serving-mysql-...

brendoncrawford 15y ago

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

davisp 15y ago
As you say, its not so cut and dry. Gunicorn has only had a mailing list since about May. Most of our dev work is based in IRC or via the GitHub issues tracker. The three committers, @benoitc, @tilgovi, and @davisp have a combined 1709 twitter followers. There are also 479 watchers and 64 forks of the main development repo on GitHub. Bottom line, numbers like this don't really mean much. In the end, people should investigate any project they think is a candidate and make a decision based on their specific criteria rather than try and use some proxy metric to make the decision.
senko 15y ago
> 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 15y ago
  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.