> I ran the tests on a 2.2GHz WinXP box, Python 2.3.3 and Twisted
> version 1.1.1.
>
> Sorry, I couldn't detect any difference between the three of
> them. Ensured
> full-reloads were taking place.

Well, crud....  That baffles me a bit.  Maybe it's a Linux thing?  (I've
spent lots of time looking hard at the select() call...  Seeing it take WAY
too long to come back, since I KNOW there's input that wants to come in.
And by 'KNOW', I mean, I haven't actually seen the request come over with a
packet sniffer or anything, but why wouldn't the browser be requesting it?)

Hmm.. Were both the server and client running on the same XP box at the same
time?  I wonder if the Windows box does something to optimize the select()
behavior over localhost connections...  I don't really see how it could.

> Incidentally -- warning, this anecdotal stuff is worth less than
> nothing! -- I
> ran apachebench against it (ab -n 100
> http://localhost:8082/index.html), and
> got much better performance from oldqx and newqx (~150 req/s)
> than with twisted
> (~105 req/s).

Oh, I couldn't agree more, except...  When I test with ab, everything runs
fine.  I suspect it's because, in twisted, if the connection is closed, the
problem goes away (though there is a performance hit for re-establishing the
connection).
For example:
(and these are BS numbers, but they loosely correspond to the reality I've
witnessed while troubleshooting this problem)

Browsing with Mozilla:
twisted with keep alives:  about .5 seconds to paint the screen
twisted without keep alives: about .75-1.0 seconds to reload
twisted/oldqx with keep alives: about 10 seconds
twisted/oldqx without keep alives: about 1 second

but with ab, I keep show things like (and these are numbers I just ran):
ab -c2 -n500 http://localhost:8082/index.html
twisted Requests per second:    192.01 [#/sec] (mean)
oldqx   Requests per second:    158.28 [#/sec] (mean)
newqx   Requests per second:    145.77 [#/sec] (mean)

ab -k -c2 -n500 http://localhost:8082/index.html
twisted Requests per second:    186.22 [#/sec] (mean)
oldqx   Requests per second:    165.29 [#/sec] (mean)
newqx   Requests per second:    154.80 [#/sec] (mean)

ab -k -c10 -n500 http://localhost:8082/index.html
twisted Requests per second:    203.92 [#/sec] (mean)
oldqx   Requests per second:    163.99 [#/sec] (mean)
newqx   Requests per second:    161.86 [#/sec] (mean)

Now, something I thought was very interesting was the way I figured out to
experiment with keep-alives;  at one point while going intrumentation happy,
I put a bug in, without realizing it.  It was right after the self.finish()
call in the QuixoteTWRequest.process() call.  The thing was, the request was
handled (calling finish() is the last thing to do), so the request was still
served, but twisted, seeing the unhandled exception, killed the channel that
was being used.  The request performance shot WAY up (from about 10req/sec
to maybe something that 'felt' more like 100).  As soon as I fixed my bug,
performance went back down :)

Weird stuff, twisted is.

> More oddness, when I tried concurrent connections (ab -n 100 -c 10
> http://localhost:8082/index.html), only the "twisted" version returned a
> response (~50 req/sec), while the qx versions just hung. Not sure
> what happened
> there, and don't have time to look into it... could be a problem
> with 'ab' on
> Win32, for all I know.

Yeah, that sounds weird...  I've seen odd results with my async based apps
before, when hitting them with ab and high concurrent user counts, but
nothing like that.

Thanks for your feedback Graham,


Jason