httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject buffer / coalesce / setaside / etc (was: cvs commit: ...)
Date Tue, 03 Oct 2000 23:34:12 GMT
On Tue, Oct 03, 2000 at 03:32:26PM -0700, wrote:
> > > > If you're already going to have to copy, why not coalesce at the 
> > > same
> > > > time?
> > >
> > >We take care of this by using the setaside function.  The reason not 
> > >to coalesce, is that we don't know if we want to or not.  Imaging a 
> > >brigade that looks like:
> > 
> > But the setaside function has to copy the data.  If you're already 
> > going to copy it, why copy it here and then coalesce it in the core, 
> > copying it again?
> You're correct.  I had forgotten that ap_r* always used transient
> buckets.  Of course, if we are going to copy it anyway, then we shouldn't

We aren't *always* going to copy it (it's quite possibly to hit the
bottom-most filter with a large enough brigade such that it is iovec'd out
to the network), so they should continue to use transient buckets when
possible. Defer the decision -- that was the basic rule we decided to
operate under.

Buffering/coalescing is not guaranteed to occur, so we should defer when

> use transient buckets, we should create one big bucket to begin
> with.  This is also more proof that all of the standard modules need to be
> re-written.

If the standard modules require rewriting, then we have done something
wrong. Right from the start, we stated that we should not *require* any of
the modules to be rewritten.

The free list for brigade structures and bucket structures "should" solve
most of (any) perf problem. Note that we can probably get away with a free
list just for transient buckets (I'm making an assumption that it is the
most common bucket type created; file buckets will be common, too, but
probably just one per request). Of course, we need actual performance data
for this stuff before we can really make a statement about how bad/good the
current stuff is and/or where it can be pushed to.

[ note that the free list won't necessarily be easy and/or fast because it
  may need mutexes to make it thread-safe. for thread-safety, we could make
  the pool per-request (per-conn?), or per-thread, or deal with mutexes ]

As an aside: I agree with (whoever said) that we should not attempt
buffering up at the ap_r* level. Again, that is "too proactive". I do
understand that it implies we could traverse the filter stack too often, but
lets get some evidence that this is really a problem. Specifically: what is
the typical filter count? Is it expensive to traverse them?

Personally, I always like the BUFF approach rather than the brigade
setaside. It is a simple way to coalesce and buffer at the same time. It was
also very efficient for single-character data written via ap_rputc().


Greg Stein,

View raw message