httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 19:48:57 GMT
rbb@covalent.net wrote:

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

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.

> It should be mentioned that even with this
> change, ap_r* will probably never be as optimal as just using buckets,

Just using buckets doesn't solve the mod_autoindex problem.  Coalescing the data
early will solve it.  Doing it in ap_r* sounds right to me.  It's not in the
modules, but immediately after them. It doesn't solve the problem of a filter
generating a lot of little pieces, but so far that's only a hypothetical problem.

> chunk_filter:  This should make sure there is a big enough buffer of
> buckets before it adds a chunk header.  It should perform no coalescing,
> ever.  To do this, the chunk filter just needs to add a call to
> ap_save_brigade.

Yup.  Peace.  I think everybody agrees about this.

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

> This also allows for different MPMs to actually implement different core
> filters.  If I am on a platform that allows an unlimited number of
> elements in my iovec, my core filter can take advantage of that

An interesting idea...

Greg


Mime
View raw message