httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 02:37:11 GMT

> > I don't see what the big deal is about a buffer filter.  Coalescing
> > is necessary if the data that is about to be sent out the network
> > is less than a defined (configurable) threshold and the stream is
> > not in a non-buffering mode.  That coalescing can take place either
> > within the TCP_CORK (if we are lucky to have one) or a buffering
> > layer.  Assuming that the module will implement writes "efficiently"
> > is not a reasonable thing for the server to do.
> >
> > This is not a question of design purity -- I was always assuming
> > that such a layer would exist, for the same reason that BUFF exists.
> AFAIAC, it is not a question of whether or not we coalesce data, it is
> where we coalesce it.  I would personally prefer to coalesce data at the
> lowest possible location, so that we aren't copying things multiple
> times.  In my head, that means that we have two possible locations to do
> the coalescing.  1 in a separate filter that just does buffering, or 2 in
> the core filter.  As much as I am in favor of small filters that do one
> thing and do them well, I really believe the core filter needs to be the
> thing to do the coalescing.

Here is the problem with coalescing in the core_filter using mod_autoindex as an example.
Mod_autoindex writes multiple very small bytes ( 1 to 8 bytes lets say) to ap_rputs which
turns each
write into a bucket which is then passed down to the chunk filter. The chunk filter then chunk
encodes each 1 to 8 byte chunk of data. The chunked encoding uses more space than the actual
content. The buffering needs to happen above the chunk filter in this example.

Perhaps introducing buffering into ap_rputs is an optiob, but it seems less clean that the
filter. Furthermore, the buffer filter does not do anything if the thresholds are not hit.
introduces minimal overhead for the cases that do not benefit from buffering.  core_filter
is the
perfect place to collect iovecs (or entire brigades) before doing network i/o, which is what
I am
attempting to do with my latest core_output_filter patch.


View raw message