httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 19:39:20 GMT
On Tue, 3 Oct 2000, Bill Stoddard wrote:

> >
> > 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.
> 
> I just reread this and I completely disagree. ap_r* needs to coalesce data in
> addition to buffering buckets. ap_r* routines can never be sure of the scope of
> the storage passed to them, so you will need to setaside all the calls. It makes
> more sense to just explicitly alloc an output buffer inside ap_r* and copy bytes
> into that buffer. When you meet your threshold conditions, turn that buffer into
> a bucket of suitable type and send it down the chain.

So, in other words, if a handler allocates small chunks of data and uses
ap_r* to write it, we will copy once in the handler, once in ap_r* and
potentially once more in core_fitler.  As opposed to copying once in the
handler and potentially once more in the core_filter.  Doing coalescing at
the top of the stack just doesn't make sense, because we have no idea if
coalescing makes sense there.  The only filter that really knows when to
coalesce is the core.

Again, take the example of a new core_filter per MPM.  This allows each
platform to define the best time to copy data into a single buffer.  Doing
the coalescing in the ap_r* functions removes this ability.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message