Some brief opinions and notes on uWSGI

February 17, 2013

From my perspective, uWSGI is a WSGI server with a boatload of additional features and options that I'm not interested in. It will serve your WSGI applications via either FastCGI or its own 'uwsgi' protocol; the former is supported by most everything and the latter is supported by at least nginx. The problems with uWSGI are twofold; it is fearsomely complex and its documentation is mostly written as reference for people who already understand it.

(I started out planning to write some sort of opinionated quickstart guide to WSGI on uWSGI, but it turns out I haven't used it enough to feel confident and the Django people sort of already beat me to it.)

uWSGI can be configured through command line arguments or by creating a configuration file. I feel that the Django example adequately shows why you want to use a configuration file.

I feel nervous about uWSGI's manageability as far as things like loading new versions of a WSGI application's code and so on. There are probably ways to do all of this if you find them in the uWSGI documentation, but at the least uWSGI does not make it anywhere near as obvious as I'd like.

For all its fearsome complexity uWSGI does work and work well, and it was not too hard to configure for my testing once I sorted everything out. I have not engaged in an extensive search for WSGI servers or testing thereof, but uWSGI handily beats flup (although now that I look, Django no longer points you to flup as a deployment choice). I expect that it's the highest-performing WSGI server available today and probably also one of the most memory-efficient ones.

(WSGI server performance may well not particularly matter to you. To put it bluntly, a relatively slow application is unlikely to care about a little extra overhead added by a slower server. I was torture-testing things with a relatively fast WSGI application in a situation with significant resource constraints.)

However, after mulling it over I've decided that uWSGI is overkill (and overly complex) for my own use. While it's better than my own hand-rolled SCGI-based WSGI server it's not hugely so, and I am much happier with my own server; I understand it better, I can control it better, and I'm not impressed by uWSGI's mostly lack of options for adaptive control of how many worker processes you're running.

(The other WSGI server I've heard of is Gunicorn, which has the advantage of being one of Django's current recommended choices for deployment but the drawback of being HTTP-based. Also, I'm sorry to say that I have a very strong bias against people who require that I turn JavaScript on in order to navigate their main site (although apparently not their documentation once you find it).)

Comparing uWSGI to Apache's mod_wsgi is really an apples to oranges kind of thing. If you already have Apache and have relatively modest needs, using mod_wsgi is easier by far than running a separate WSGI server (regardless of the specific WSGI server). The drawback is that it requires you to run Apache and you pay a relatively significant memory penalty. I'm pretty sure that I couldn't really run mod_wsgi on a a 512 MB virtual server and stand up to any significant load (at least not without very advanced Apache tuning), whereas both uWSGI and my SCGI WSGI server (both running behind nginx) did quite well with minimal tuning.

Sidebar: some notes on uWSGI

The Django example shows an unrealistically low number of worker processes in my opinion; you probably want more, and if you want more you probably want to turn on uWSGI's adaptive process handling.

Unless you turn it off, uWSGI logs one (verbose) line per request it handles. This is turned off with the misleadingly named 'disable-logging' directive, which should really be called 'disable-request-logging'. If not changed, uWSGI logs to standard output (or maybe standard error).

Written on 17 February 2013.
« Finding out what TLS/SSL cryptography people actually get with your servers
The strikes against Solaris 11 for us »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Feb 17 02:06:28 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.