httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 19:58:06 GMT

> > ap_r*.  These are older functions.  They are likely to always work,
> > because they are very useful.  Currently, they have horrendous
> > performance.  The way to solve this, is to allow ap_r* to buffer data.  If
> > multiple calls to ap_r* are made, the buckets should be buffered until it
> > is worth it to send the data.
> That solves the "excessive number of trips down the filter chain" problem, but
> doesn't solve the "excessive number of buckets to
> create/initialize/examine/destroy"  problem.  Both will cause performance hits
> with the mod_autoindex scenario.

The way to solve this is to stop allocating buckets everytime they are
needed.  We need to keep a free list of buckets, so that we are just doing
pointer manipulation, but nobody has had the time to implement this yet.

> And yes, we should keep mod_autoindex as-is for a test case.  Changing the modules
> to do internal coalescing would be like putting on rose colored glasses, in
> addition to being effort spent in the wrong place IMO.

No, we should not.  If you want a test case, create a small module that is
not used in the server.  Using a module written for a previous version of
the server is a bogus test case.

> > core_filter:  This filter should take the brigade it is sent, and coalesce
> > it.
> That's too late.  This forces many more buckets to be touched on the way down the
> filter chain than we would need to if we coalesced at the top.

Touching multiple buckets is just a bit more pointer manipulation.  It is
not a performance issue, once we have a free list.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message