httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: layered I/O (was: cvs commit: ...)
Date Wed, 29 Mar 2000 05:48:51 GMT
>On Mon, 27 Mar 2000, Roy T. Fielding wrote:
>
>> Whatever we do, it needs to be clean enough to enable later performance
>> enhancements along the lines of zero-copy streams.
>
>good luck, i think it's impossible.  any code written to a read/write
>interface is passing around buffers with no reference counts, and the
>recipients of those buffers (the i/o layers) must immediately copy the
>contents before returning to the caller.  zero-copy requires reference
>counted buffers.  therefore any future zero-copy enhancement would require
>substantial code changes to the callers -- the modules.

Yes, assuming we did zero copies.  We could still do the interim thing
with one-copy.  I agree that taking advantage of the higher performance
would require that the callers be attuned to the high-performance interface.

>btw -- the code, as is, already supports zero-copy for those cases where
>it's actually a win... the cases where bwrite() is called with a large
>enough buffer, and we're able to pass it to the kernel immediately.
>
>i honestly believe there are very few applications which benefit from
>zero-copy.  encryption and compression obvious don't, they require a copy.  
>what other layers would there be in the stack?
>
>a mod_include-type filter which was doing zero-copy would probably be
>slower than it is now... that'd be using zero-copy to pass little bits and
>pieces of strings, the bits and pieces which were unchanged by the filter.  
>zero-copy has all this overhead in maintaining the lists of buffers and
>the reference counts... more overhead in that than in the rather simple
>heuristics present in BUFF.

On the contrary, the vast majority of include-based templates
consist of large junks of HTML with embedded separators.  With zero-copy
you can just split the data into three buckets by reference and
replace the middle bucket with the included content, which may
itself be a data stream.  Not only does this reduce memory consumption,
it also removes almost all of the special-case handling of data sources
via subrequests/caching/proxy/whatever and vastly simplifies the
SSI/PHP/whatever processing architecture.

>a MUX layer might benefit from zero-copy ... but after doing lots of
>thinking on this a year ago i remain completely unconvinced that zero-copy
>from end to end is any better than the heuristics we already have... and
>the answer is different depending on how parallel mux requests are
>serviced (whether by threads or by an async core).

The place where I need zero copy is in the request processing, where
the first read off the network may result in multiple requests being
placed within the same buffer.  I don't want the initial request to
be copied into separate buffers, since I still consider that initial
copy to be more overhead than all of the reference counting combined.
Maybe I'm just being too pessimistic about the cost of a data copy,
and I should optimize around one-copy instead.

....Roy

Mime
View raw message