[Twisted-web] A twisted wsgi success

[Ian Schenck]

Gelin,

I'm loathsome to share my data as benchmark data. We came up with an
acceptable range of performance before we set out, decided on what to test
and how based on real traffic, and did a very short test to confirm we were
ok. We picked a particular page that hits a few of our internal systems. We
ran the benchmark against 3 twisted processes with default threadpool
parameters vs the other with 8 workers on a single core VPS. We don't care
about 2 or 10 or probably even 50 milliseconds. We didn't bother tuning the
old setup (or maybe we did in the past before I arrived). We really just
wanted to check for a huge, perceptual regression in performance. We were
comfortable enough with this test to use it, but I wouldn't refer to it or
publish it as a benchmark.

With that disclaimer, I've attached a graph of mean and standard deviation
in our particular test.


Run with:
ab -c 1 -n 100
ab -c 10 -n 1000
ab -c 25 -n 5000

I don't know if I have complete output from ab anymore.

On Wed, May 20, 2015 at 10:06 PM Gelin Yan <dynamicgl at gmail.com> wrote:

> On Thu, May 21, 2015 at 1:56 AM, Ian Schenck <ian.schenck at gmail.com>
> wrote:
>
>> I mostly lurk on here, but I wanted to share my recent experience
>> switching my company's wsgi container to twisted wsgi.
>>
>> 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.
>>
>>
> Hi Ian
>
>     Could you tell me a bit your benchmark data? I am interested in moving
> our container to twisted recently.
>
> Regards
>
> gelin yan
> _______________________________________________
> Twisted-web mailing list
> Twisted-web at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-web/attachments/20150521/869ca54a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Request-Response Latency.png
Type: image/png
Size: 60415 bytes
Desc: not available
URL: <http://twistedmatrix.com/pipermail/twisted-web/attachments/20150521/869ca54a/attachment-0001.png>