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
