We had been using a particular wsgi container implemented in C. As time went on problems creeped up with cython modules, segfaults happened, and threading had to be disabled. Things that worked in development would not work in production. At this point I wanted two things: the development container should be the production container, and the container of choice should provide a python interpreter environment consistent with actual python. These containers written in C which treat your application like a plugin fail to do that across the board.

We no longer have any of the issues we had before (cython, threading, segfaults), and if something were to break in production, it is probably broken in development and won't make it out the door. Development servers run the same twisted wsgi container that runs in production, in fact they are both launched the same (but middlewares and reloaders differ). That consistency is a really big deal. Additionally, deployment and config management dropped a few hundred lines.

The biggest pushback I received was over performance. We benched our real world application (versus, ahem, just returning a string) and found our median response time was consistently 1-2ms higher across various concurrency levels. That's insignificant for us. Under high load, twisted wsgi actually did better with tail latency (99%ile and max). Maybe that slight bump in median latency is because our web workers now speak http instead of a "light weight protocol" akin to scgi, but the benefits of talking http (curl much?) are also worth a millisecond or two.

Thanks for all the hard work, and thanks Glyph for your 2011 Djangocon talk and your tweets leading me to twisted wsgi. We're very happy. If anyone wants details or a peek at some of the wiring, I can probably get approval to share more.