25

I'm using nginx + fastcgi( manage.py runfcgi ...) on production for some of my Django projects. A lot of people suggests to use nginx + gunicorn. What is advantage of using gunicorn instead of using Django's fastcgi server?

Bali C
  • 30,582
  • 35
  • 123
  • 152
Murat Çorlu
  • 8,207
  • 5
  • 53
  • 78
  • 1
    FastCGI Deprecated since version 1.7: FastCGI support is deprecated and will be removed in Django 1.9., so i suggest go for uWSGI. – ashish Oct 03 '13 at 14:46

2 Answers2

29

I'm just tell why you need to use WSGI-like servers :) but if you feel comfortable with using fcgi - just use it

Short answer: WSGI (as protocol) is cool because its native

Or if "You need to go deeper"(c)

Next question "FastCGI vs WSGI-like servers?"

Some answers here:

About gunicorn, uWSGI and cherokee, nginx. Dont mix them!

nginx is web-server which can handle http requests and can send it to WSGI backend. ( But first of all it extremly fast for static content handling. ) And WSGI backend handle you django application.

About cherokee, I think it handle the same tasks as nginx but I'm not work with it.

And gunicorn, uWSGI are WSGI backend which run threads with django app and do many other tasks

And hmmm, gunicorn say that

Being a server that only runs on Unix-like platforms, unicorn is strongly tied to the Unix philosophy of doing one thing and (hopefully) doing it well. Despite using HTTP, unicorn is strictly a backend application server for running Rack-based Ruby applications.

I practice for my django apps nginx (latest stable from nginx.org repos)+uWSGI (from Debian stables) - works perfectly :)

edited 18.05.2012

Link to 2010 topic with comparing fcgi gunicorn uWSGI

fcgi (threaded) 640 r/s

fcgi (prefork 4 processors) 240 r/s (*)

gunicorn (2 workers) 1100 r/s

gunicorn (5 workers) 1300 r/s

gunicorn (10 workers) 1200 r/s (?!?)

uwsgi (2 workers) 1800 r/s

uwsgi (5 workers) 2100 r/s

uwsgi (10 workers) 2300 r/s

(* this made my computer exceptionally sluggish as CPU when through the roof)

Community
  • 1
  • 1
b1_
  • 2,069
  • 1
  • 27
  • 39
  • 8
    "FastCGI vs. WSGI" is the wrong question. FastCGI is a network protocol and WSGI is a Python calling convention. [flup](http://trac.saddi.com/flup) has a FastCGI-to-WSGI gateway. Django’s `runfcgi` command is actually based on flup, and thus uses WSGI. A better question is flup vs. uwsgi or flup vs. gunicorn. – Simon Sapin Jul 19 '12 at 14:22
  • You are right about "FastCGI vs. WSGI". Change in topic to WSGI-like. And I think battle `flup vs. uwsgi vs. gunicorn` win uWSGI. I'll try to provide some proofs soon. – b1_ Jul 19 '12 at 17:20
  • 3
    Well, who "wins" depends on what’s your criteria. I’m hosting a dozen sites with low traffic, so ease of maintenance and memory usage are more important *for me* than raw performance (which is dominated by database queries anyway.) uwsgi is not packaged in debian squeeze (the current stable), while flup and gunicorn are. – Simon Sapin Jul 20 '12 at 05:44
  • 2
    just a heads up: implying that gunicorn is not a good solution for Django because it is intended to be used with Ruby is flat out wrong. The poster got gunicorn and unicorn mixed up - the quote is taken from unicorn (a Ruby http server), not gunicorn. – jthurner Oct 08 '14 at 13:54
4

As b1- says, WSGI is native (take a look at this post).

Also, this post has a similar question.

From my personal point of view, some time ago i've been using Nginx + uwsg in vhost mode to run various project on my server.

Community
  • 1
  • 1
reiven
  • 71
  • 1
  • 5