4

I've searched around on this topic, and the advice seems to be that nginx should be there to serve static files and apache+wsgi for dealing with Django. A lot of this information is a couple of years old, so I was wondering if there was a way to simplify this without performance degradation and just rely on Nginx and fastCGI and/or wsgi.

I'm new to non-heroku deployment, so this is why I probably sound like I don't know what I'm talking about.

Scott
  • 293
  • 5
  • 12

2 Answers2

5

No you don't need Apache+wsgi along with Nginx+fCGI/wsgi. Nginx can serve static files really fast and it will use fCGI/wsgi for rest of the requests.

You should read answer to this questions[1] and other related questions mentioned there.

[1]. What is the disadvantage of using Django's fastcgi server

Community
  • 1
  • 1
pankaj28843
  • 2,458
  • 17
  • 34
3

If you want to go the nginx route, the best choices are:

  • nginx -> gunicorn
  • nginx -> uWSGI

Running Python WSGI applications on top of FASTCGI is not generally as good an experience due to issues with the FASTCGI/WSGI adapters and how they are deployed with servers.

Apache/mod_wsgi is still a more than acceptable solution and it will actually perform better with less resources when run as:

  • nginx -> Apache/mod_wsgi

Because the bottlenecks aren't going to be the web server, ultimately it doesn't matter which you choose, so long as you set it up properly, something which most people wouldn't do as there site doesn't get enough traffic anyway, or they have no monitoring in place to know what they need to change.

Overall, picking which you think is easier to manage is the best thing to do when starting out.

For some background on what your real performance bottlenecks are going to be and the importance of monitoring, watch:

That all said, you mention Heroku. Right now there is really only the once choice with Heroku and that is to use gunicorn and you wouldn't need to be worrying about nginx. That is a problem in itself though, as gunicorn alone is not a good option for serving static media assets so almost forced with Heroku to serve static assests elsewhere.

Graham Dumpleton
  • 57,726
  • 6
  • 119
  • 134
  • *FASTCGI is not as good an experience for Python web applications.* Do you have any proofs? FastCGI is just a protocol, and it is worth noting a very good protocol with error reporting and keepalive support. – VBart Nov 22 '12 at 18:17
  • Half a decade of providing support to people trying to get Python web applications to run on mod_python, FASTCGI, SCGI, AJP and WSGI variants says that FASTCGI has always been the one that gives the most bizzare problems. More so with Apache FASTCGI, but nginx wasn't far behind. Your typical web hosting companies FASTCGI offerings are also pretty poor when it comes to trying to use Python. For some background, have a read of http://blog.dscpl.com.au/2011/09/why-is-wsgi-deployment-under-fastcgi-so.html and http://blog.dscpl.com.au/2009/04/improving-commercial-pythonwsgi-hosting.html – Graham Dumpleton Nov 22 '12 at 22:14
  • It seems you are confusing protocol with its implementation. Apache is not nginx. What problems do you have with nginx fastcgi? – VBart Nov 23 '12 at 02:08
  • When I say 'experience' I mean the deployment experience around WSGI adapters for FASTCGI and the mechanisms for setting up the servers to make it simple for users to deploy WSGI applications. I am not taking issue with the FASTCGI protocol itself, whatever server it is implemented in, but that deployment experience. It could be made better as I have blogged about in the past, but still it is quite poor, especially with Apache/mod_fcgid. – Graham Dumpleton Nov 23 '12 at 04:12