httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: How to achieve zero-copy when reading request headers?
Date Mon, 01 Jul 2002 04:14:20 GMT
On Sun, 2002-06-30 at 20:57, Justin Erenkrantz wrote:
> On Fri, Jun 28, 2002 at 07:01:34PM -0700, Ryan Bloom wrote:
> > Have you looked at which of these are causing the most performance
> > problems?  It seems to me that the easiest thing to do, would be to use
> > a persistent brigade, which removes two steps from this.
> 
> I'd really prefer that we decouple this persistent brigade from the
> request_rec.  We used to have it coupled (req_cfg->bb) and it made
> the code too confusing as other places started to rely on this
> brigade.  So, I'd like to not go back down that road and figure out
> a better scope for such a persistent brigade (a filter context seems
> about right for the scope).

The brigade can't be in a filter context, because then it wouldn't be
accessible from ap_rgetline_core().  The request_rec is the only place
where we could easily put this brigade.  We just need to name it
something like "temp_working_brigade" and document the fact that any
function that puts things in that brigade must clear them out before
it exits.

> Yet, my real desire here is to figure out how to make brigade creation
> and destruction faster.  I think the problem is that pool cleanup
> registration and destruction is *very* slow.  So, perhaps, that'd
> be the place to focus on if we're concerned that brigades are just
> too expensive.  If we're going to go to all of this hassle to avoid
> creating brigades (which IMHO should be cheap to create and destroy),
> then that means we should speed this up instead of avoiding this real
> problem.  I don't see why a brigade should be a heavyweight object -
> they seem like they should be extremely lightweight.

The pool cleanup registration and cancel operations aren't particularly
inefficient (though I think there's some room for optimization).  The
problem is the large number of calls to these operations per request,
due to the multiple brigade creations/deletions per header line.

--Brian



Mime
View raw message