httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 14:11:18 GMT

I want to be very clear about my position about ap_r*, the chunking filter
and the core filter.  Because I have failed completely to get this across
by replying to other posts, I am going to just write it as clearly as I
can.  :-)  If this is not completely clear, or if it doesn't make sense,
please let me know.

some old def's so that they are here. :-)

buffer:  Storing groups of data in one place.  The most obvious way to
buffer data is to add buckets to the end of a brigade

coalesce:  Combine multiple buckets into the optimal number of buckets

ap_r*.  These are older functions.  They are likely to always work,
because they are very useful.  Currently, they have horrendous
performance.  The way to solve this, is to allow ap_r* to buffer data.  If
multiple calls to ap_r* are made, the buckets should be buffered until it
is worth it to send the data.  It should be mentioned that even with this
change, ap_r* will probably never be as optimal as just using buckets, but
it will be much better than it is now.  The reason for this, is that the
buckets interface has a different mindset than ap_r*.

chunk_filter:  This should make sure there is a big enough buffer of
buckets before it adds a chunk header.  It should perform no coalescing,
ever.  To do this, the chunk filter just needs to add a call to

core_filter:  This filter should take the brigade it is sent, and coalesce
it.  This needs to be done in one location for performance reasons.  As
everybody has said, for small chunks of data, it is always faster to
copy.  This is true 99% of the time, but not 100% of the time.  Imagine
this case:

We get a brigade with five buckets, one with 8950 bytes, the other
five make up a total of 50 bytes.  It makes no sense to copy the 50 extra
bytes.  Create an iovec out of a pool, and use apr_sendv to send the
data.  As long as we have fewer than 16 iovec elements, we should be using
iovecs.  If we have more than 16 elements, we need to coalesce to 16

This also allows for different MPMs to actually implement different core
filters.  If I am on a platform that allows an unlimited number of
elements in my iovec, my core filter can take advantage of that while
another platform doesn't.

This should explain my position.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message