Re: [Twisted-web] A twisted wsgi success

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 wrote:

On Thu, May 21, 2015 at 1:56 AM, Ian Schenck 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@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web