On Apr 18, 2017, at 9:02 PM, Craig Rodrigues <rodrigc@crodrigues.org> wrote:

On Mon, Apr 17, 2017 at 2:10 AM, Hynek Schlawack <hs@ox.cx> wrote:

I have to disagree here BTW.  When I started using Twisted as a WSGI container, I was vexed by its lack of docs (and I’m still confused about many details).  There’s a few blog posts around but none of them reach the straight-forwardibility of e.g. gunicorn’s docs.  I’ve ended up asking around on IRC, stealing from Donald/PyPI, and reading source code.

I honestly believe, we’re leaving money on the table here.  Using Twisted as a WSGI container should be first class use case on the web page since it presents a nice entry drug into the ecosystem.


If someone was not dedicated to Twisted, why would they even bother going through all the steps that you did to
figure out how to use Twisted as a WSGI container?  I'm amazed that even you did not give up. :)

Do you have any idea how Twisted fares in performance benchmarks of WSGI containers?
Moshe's presentation didn't cover this, and I forgot to ask him at the presentation.
I also couldn't find any WSGI benchmarks which included Twisted.

Do be honest, it probably doesn't do all that well.  Making the container multi-process (as Moshe notes) would be a good first step to getting something worth benchmarking.

But, I should note, the obsession with benchmarks in WSGI containers is a symptom of a generally industry-wide lack of understanding of good performance analysis.  The fastest WSGI container is probably 2% of your application's overhead; the slowest possible one, maybe 3%.  The differences look huge when you're comparing servers against each other, but throw a real application and a database and some load balancer latency in there and the app server container utterly disappears.  Even multi-process support isn't really about optimizing for performance (although certainly leveraging multiple cores helps), it's about being able to safely crash a WSGI container process without bringing down the whole server.

-glyph