[Twisted-web] making streams optional in web2

[Glyph Lefkowitz]

On Thu, 2006-02-09 at 13:40 -0500, James Y Knight wrote:

> Benchmarking is a dangerous activity.

Truly.

> I only get 131req/sec from ab on my mac from the following IResource  
> resource, vs 114 from the wsgi resource, vs 706 from apache. Vs 74  
> from cherrypy's tut01_helloworld.py.

This is encouraging, at least with respect to the relative speed of
CherryPy.  I'd be quite happy to be wrong about needing API changes to
improve performance; these should be independent considerations.

> So, shrug, I'm sure my benchmark  
> sucks, and must be measuring something completely different than  
> yours, given the wide variance in relative numbers. Anyhow, I'm happy  
> that someone is benchmarking web2, because I haven't done so any time  
> recently, but what you write above comes quite close to random flaming.

I was hoping JP would publish his actual results before I wrote what I
did, but I didn't want the ideas to get too stale.  Maybe this will
prompt him to - I hope said results are not too different from what I
remember. 

At any rate, don't take it to heart, I'm glad just to get some
discussion started about this and have everybody following it on the
list publish their own trivial benchmarks to see if we can achieve some
consensus as to how much load web2 can actually handle these days.
Perhaps I should have been more direct in the first email, though.  Full
disclosure: I never liked streams as an API, and I have practically been
looking for reasons to complain about them.  Look for more soon, this
benchmark was only the first ;-).

Also, performance and aesthetic considerations aside, if a thing says it
implements IConsumer, it should *actually* implement IConsumer.  Is the
mistake in the declaration or the implementation here?  I hope it's the
implementation, because IConsumer is the API I'd prefer to use, streams
or no.  Or, is there some funny magic behind the scenes where a Response
actually does provide IConsumer somewhere?  Even if so, a
directlyProvides makes more sense for funny magic than an implements().

> Here's all the construction of Deferreds from the native response.

Hmm.  It is quite possible that the profile was not accurate - there
were some odd things about it, although it's also possible that the WSGI
test in question was doing something pathological that yours was not,
like generating tons of tiny little write()s.

> Only one is from the streams module. Looks like some of the others  
> could be removed without changing any APIs, if that actually helps  
> things. Going through the WSGI interface adds one additional deferred  
> construction in addition to these 4.

Deferreds do have an embarrassingly high overhead.  The next step here
(in figuring out if those extra deferreds should be eliminated) is
probably for me to construct some more meaningful benchmark to measure
the performance impact in req/sec of additional deferreds in the
response pipeline.