httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Fri, 29 Sep 2000 19:20:32 GMT
One more requirement.....
Whatever solution we eventually use will need to not rely on core_filter sending
huge numbers of  iovecs using apr_sendv().  Some systems limit the number of
iovecs that can be sent on one call to writev(), and the overhead of setting up
and sending iovecs each containing just a few bytes is probably not much
different that he overhead of moving those bytes into a common buffer. Food for
thought...

Bill

> > stoddard@locus.apache.org wrote:
> > >
> > >First cut at a filter to buffer/coalesce multiple small buckets into
> > >a single large bucket.
> >
> > The whole
> > point of buckets is to avoid copying,
>
> Avoiding copying is a good general design goal, but I question the wisdom of
> dogmatically pursuing this goal without considering code complexity or the
> impact on Apache module writers.  And buffer filter will not move ANY bytes
when
> working with file or pipe buckets for all common cases of interest (today :-).
>
> > so whe should re-do the ap_rput
> > stuff so that copying isn't needed in the first place and re-do
> > mod_autoindex so that it uses buckets directly.
> >
>
> How much complexity will be added to ap_rput, et. al. to avoid a few byte
> copies? Ditto question for mod_autoindex?  I agree in principle that
> buffer_filter may not be the best solution, but it is a significant
improvement
> over what we have today. Get ap_rput and mod_autoindex working (perhaps I'll
> give it a shot) and lets see how the two techniques compare. If you are right,
> I'll gladly remove the buffer_filter.
>
> Bill
>


Mime
View raw message