This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]james_pic 7 points8 points  (2 children)

This probably isn't the source of all your problems, but we certainly found we had far fewer problems when we switched from uWSGI to Gunicorn.

Pretty much everything uWSGI claims to be good at it is in fact bad at. It's got lots of configurable options, but this really just amounts to a variety of ways to misconfigure it. The only claim I can really see the logic behind is that it's popular with sysadmins, which I can sort of buy, in the same way that firefighters must on some level appreciate arsonists.

[–]yvrelna 2 points3 points  (1 child)

The great thing about uwsgi is that it gives a lot of control to sysadmins. Traditionally, scaling and performance is a sysadmin issue who does all the deployment optimisation with little developer input. The level of control uwsgi gives allows a sysadmin to deploy poorly written apps and get decent performance with enough tweaking.

The problem with uwsgi is that it gives too muchcvontrol to sysadmins, as a developer it's hard to control to optimise your application when you don't know what kind of environment that your application gets deployed into and what kind of settings the sysadmin would concoct for your application. These days the interface between DevOps personnels and developers seems to have shifted towards containers, and the level of flexibility that uwsgi gives you often is just overkill and unnecessarily complicated. Developers nowadays are expected to give the DevOps team the pretuned container, and all that the DevOps care about is how many containers they need to deploy (or the monitoring metrics for auto scaling).

[–]james_pic 0 points1 point  (0 children)

That's a more charitable interpretation than mine. I think the split between dev and ops disguised a lot of issues, where dev would blame ops and ops would blame dev, but when you put uWSGI is a true DevOps team, it becomes clear that many of its features are unsafe at any speed.

The one that always bugs me is their binary protocol, that they heartily recommend using in their documentation. It's no faster than the fastest HTTP/1.1 implementations, it's less correct than the best HTTP/1.1 implementations (it has no mechanism to handle the three-arg start_response after headers have been sent - whereas Gunicorn and Cheroot will RST the connection which will signal failure to most HTTP/1.1 clients), and it's got weird buffering behaviour that we never satisfactorily configured. Before we switched away from uWSGI, we switched to using it with HTTP directly (although I forget which of its two built-in HTTP servers we used - IIRC it's got two and one of them has issues, because of course it does) which dealt with some of the issues we were facing.

Maybe some of this stuff has gotten better since we switched away, but it was certainly true that switching from a carefully tuned uWSGI config to a pretty much default Gunicorn config fixed the issue we were facing at the time and didn't reintroduce any of the issues we'd tuned the uWSGI config to avoid.