httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: How to achieve zero-copy when reading request headers?
Date Mon, 01 Jul 2002 03:57:54 GMT
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).
 
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.

> Until we know where the performance problems are in the current model I
> believe that it makes little sense to redesign the whole model.  I think
> you can stream-line this by just re-using the same brigade for every
> header and by moving the copy down to the HTTP_IN filter.

HTTP_IN is designed to read the entity - not the headers.  HTTP_IN is
only active after the request has been setup and the headers have
been read.  At this stage, HTTP_IN isn't active, so I'm slightly
confused what you'd move to HTTP_IN.

As far as connection level filters having access to the request, you
are right that they do.  However, I don't believe that the connection
filters should be modifying its request_rec since it may change on
each invocation of the filter and something strikes me as wrong if a
connection filter plays with the request - to me, that means it is a
request filter.

None of the two connection-level input filters we have now (SSL and
core) access the request_rec in ap_filter_t.  We used to modify the
request in the old HTTP_IN when it was a connection level filter and
that got us in a world of confusion.  -- justin

Mime
View raw message