httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <>
Subject Re: eek. poor chunking behavior.
Date Mon, 11 Sep 2000 22:39:18 GMT
Greg Stein <> wrote:
>Manoj Kasichainula wrote:
>> What are the ill effects of this? Small chunks (greater than a few
>> hundred bytes anyway) are slightly wasteful, but not really that bad
>> as far as I can tell. Now, if the chunks are 3 bytes, or if each chunk
>> is being send out as a seperate packet, that would be really bad.
>Calling ap_rputc('<', r) will generate a chunk. So you have
>single-byte chunks(!) BUFF is still present, so it is aggregating
>network packets. But each ap_r*() function is generating a separate
>> Still, preventing this would be a good thing. Maybe the buffering
>> filter should be inserted before chunking? 
>When we get it... yes, it probably makes sense to place it before the

I quite like that idea, because otherwise the same buffering logic
would be duplicated in the chunking filter and the core filter. OTOH
that logic is relatively simple...

The real problem is that the ap_r* functions at the moment are grossly
inefficient -- writing a single character should not result in a trip
down the filter stack! At the design meeting we talked about
optimising them by fiddling with the data inside a HEAP bucket if it
happens to be at the end of a brigade, but I've now realised this is
wrong because HEAP buckets end up trying to do two things; there
should instead be another type of bucket which is specifically for
handling little data like single characters and the result of printf,
and which is just for the ap_r* functions to fidlle with as they wish.
Other functions would still use TRANSIENT buckets as in the existing
code, except that ap_pass_brigade would not necessarily be called
every time an ap_r* function is called.

This would introduce a bit of buffering into the compatibility API,
with the result that we only go through the filter stack with a
reasonable amount of data, which would negate the need for special
setaside handling in the chunking filter and possibly the core filter

There's a problem with EOS in this scheme; to make things optimal in
the normal case there will be just one trip through the filter stack
with a brigade consisting of two buckets (a FILE and EOS, or a PIPE
and EOS...). If the handler is using ap_r* then it won't send an EOS
(and there may be some buffered data lurking) so it'll have to be sent
by ap_finalize_request.

This does imply that mixing old & new is a no-no, but you wouldn't
want to do that anyway.

en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y
eatp o v eiti i d.

View raw message