99

Could anyone please explain pros/cons when using WSGI VS uWSGI with Nginx.

Currently i am building up a production server for the Django website which i have prepared but unable to decide whether should i go with WSGI or uWSGI. Could you please explain in detail what differentiates each configuration? Which configuration should scale the best?

Thanks in advance

fear_matrix
  • 4,912
  • 10
  • 44
  • 65
  • 27
    WSGI is a specification. uWSGI provides an implementation of the WSGI specification. You can't compare them. You can only compare different implementations. – Graham Dumpleton Oct 12 '11 at 21:22
  • 1
    [This blog post](http://nichol.as/benchmark-of-python-web-servers) is a very detailed comparison of alot of Python WSGI servers, with a summary and some recommendations at the end. – Lowe Thiderman Oct 12 '11 at 12:11
  • And also uses configurations for some servers which are really dodgy and makes them appear worse than they can be. One has to be careful what one reads in to that comparison. – Graham Dumpleton Oct 12 '11 at 21:20

3 Answers3

112

Ok, guys this confusion is because of lack of detail from several sources, and the naming of these protocols, and what WSGI actually is.

Summary:

  1. WSGI and uwsgi both ARE protocols, not servers. It is used to communicate with web servers for load balancing and especially to take advantage of extra features that pure HTTP can not provide. So far Nginx and Cherokee have implemented this protocol.
  2. uWSGI is a server and one of the protocols it implements is WSGI (do not confuse the uwsgi protocol with the uWSGI server). WSGI is a Python specification. There are several implementations of the WSGI specification and it's intended to be used for more than just application servers/web servers, but there are quite a few WSGI application servers (ie. CherryPy, which also happens to have a production ready WSGI compliant web server, if you weren't confused enough already!).
  3. Comparing uwsgi to WSGI is comparing oranges to apples.
d512
  • 32,267
  • 28
  • 81
  • 107
Derek Litz
  • 10,529
  • 7
  • 43
  • 53
  • 3
    Typo: "1. **uwsgi** is a protocol not a server." --> "1. **WSGI** is a protocol not a server." – Aman Apr 10 '12 at 22:46
  • 9
    Actually, what I've written for 1 is correct, but it's true WSGI is a protocol as well as uwsgi, so both statements you have written are correct :). Of course, without the rest of the context of 1. It's the protocol used by uWSGI server. http://wiki.nginx.org/HttpUwsgiModule, - "Do not confuse the uwsgi protocol with the uWSGI server (that speaks the uwsgi protocol)" – Derek Litz Apr 11 '12 at 04:21
  • 4
    Ah, okay. I had thought you were trying to draw a contarst between statement 1. "wsgi is a protocol.." and 2. "uwsgi is a server that implements the protocol". – Aman Apr 18 '12 at 23:27
  • 3
    @DerekLitz, On which servers django runs when we do `python manage.py runserver`? – Piyush S. Wanare Feb 26 '17 at 07:25
  • `python manage.py runserver` is an internal server built in to Django. It is not apache, nginx, gunicorn or anything else. `django-extensions` provides a `runserver_plus` that uses the Werkzeug framework, but that's as close to a server as any `runserver` gets. – Mike DeSimone Aug 09 '17 at 10:36
  • 1
    What is a "Python specification"? – Armen Michaeli Nov 22 '19 at 11:57
35

It is generally best to run Python in a separate process from your main web server. That way, the web server can have lots of tiny threads that serve static content really fast, while your separate Python processes will be big and heavyweight and each be running their own Python interpreter. So plain WSGI is bad, because it bloats every single one of your nginx threads with a big Python interpreter. Using flup or gunicorn or uWSGI behind nginx is much better, because that frees up nginx to simply serve content, and lets you choose how many tiny light nginx threads to run, independently of your choice of how many heavyweight Python threads you bring up to serve dynamic content. People seem very happy with gunicorn at the moment, but any of those three options should work fine.

Going forward, it also frees you up to move the Python to another server when load starts to get serious.

Graham Dumpleton
  • 57,726
  • 6
  • 119
  • 134
Brandon Rhodes
  • 83,755
  • 16
  • 106
  • 147
  • 1
    Am a bit confused by your answer. I can't see that he mentioned running any sort of WSGI implementation inside of nginx. He referenced the main wsgi.org site. His original comparison between WSGI and uWSGI is thus a bit silly in the first place because uWSGI is an implementation of the WSGI specification. You yourself have used generic WSGI term in a confusing way in saying that 'it bloats every single one of your nginx threads with a big Python interpreter'. The WSGI specification itself can't do that, only implementations can. – Graham Dumpleton Oct 12 '11 at 21:17
  • 1
    It could make sense if we were comparing nginx + mod_wsgi (the pluggable module) and nginx + uWSGI (the application server container). – clime Feb 23 '13 at 16:57
  • So when it comes to using Nginx to run Python web apps, since Manlio Perillo's mod_wsgi is deadware and not recommended, the good solutions are either WSGI with either gunicorn or uWSGI, or FastCGI with Flup? – Gulbahar Mar 27 '13 at 15:49
  • Isn't NGINX able to separate request for static content from other request? Isn't that part of the role of a web server? – Magnus Lind Oxlund Jul 10 '22 at 17:47
20

I believe this right here http://flask.pocoo.org/docs/deploying/uwsgi/ is a good answer to clear up the confusion. The question isnt silly, happens to anyone who sees the two terms and has no prior info on how things work outside of mod_PHP world (for e.g. nothing against php or folks)

The site does well to explain in practical terms what is needed and what is the difference as well as a good deployment example for nginx.

For the convenience, the explanation from Flask wiki is quoted here:

uWSGI is a deployment option on servers like nginx, lighttpd, and cherokee; see FastCGI and Standalone WSGI Containers for other options. To use your WSGI application with uWSGI protocol you will need a uWSGI server first. uWSGI is both a protocol and an application server; the application server can serve uWSGI, FastCGI, and HTTP protocols.

The most popular uWSGI server is uwsgi, which we will use for this guide. Make sure to have it installed to follow along.

Community
  • 1
  • 1
Abhishek Dujari
  • 2,343
  • 33
  • 43