Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django Setup using Nginx and Gunicorn

senko.net

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Django Setup using Nginx and Gunicorn

#31

Post by davisp »

brendoncrawford wrote: post #30

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

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.

Re: Django Setup using Nginx and Gunicorn

#32

Post by senko »

brendoncrawford wrote: post #30

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

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

Re: Django Setup using Nginx and Gunicorn

#33

Post by unbit »

senko wrote: post #32
brendoncrawford wrote: post #30

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

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

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.

Re: Django Setup using Nginx and Gunicorn

#34

Post by ehutch79 »

senko wrote: post #16
ehutch79 wrote: post #14

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.

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

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

Re: Django Setup using Nginx and Gunicorn

#35

Post by senko »

ehutch79 wrote: post #34
senko wrote: post #16

Earlier quoted context omitted.

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

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

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.

Re: Django Setup using Nginx and Gunicorn

#36

Post by slig »

Stiffy wrote: post #28
slig wrote: post #19

Earlier quoted context omitted.

Less packages to keep updated, thus less maintenance.

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 numbe…

Excellent points. Thanks!
Post reply on HN