httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: How to achieve zero-copy when reading request headers?
Date Sat, 29 Jun 2002 12:38:06 GMT
> From: Justin Erenkrantz []
> 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
> > 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).

No.  Please use the core_request_config->bb variable for this.  That
structure is protected by CORE_PRIVATE.  The vector in the request_rec
was specifically designed for this kind of thing, so not using it
because people don't understand the API is completely bogus.  Document
the API better if that is the problem.

> > 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
> > 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.

Yes, you would need to move where HTTP_IN is located in order for the
design to work.

> 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.

Of course they shouldn't be modifying the request_rec directly.  I read
all of the messages as though you were still going to pass the data up
to ap_getline() to do anything with the data, not modify the request_rec
inside the filter.  -1 on using the filter like that, because it removes
any chance for any other input filter to re-write the headers as they
are read.


View raw message