Re: 2.0 performance Re: Breaking something? Now is the time?

[Brian Pane]

Brian Pane wrote:

> Bill Stoddard wrote:
>
>> mod_mem_cache bypasses most all of those things. Using mod_mem_cache to
>> cache a buffer in heap (contents of a 500 byte file).  I have even 
>> hack the
>> code slightly to turn off the pipelined request optimization. I am 
>> playing
>> with a new tool so I don't fully grok the output just yet but here is 
>> what I
>> see serving a single keep alive request out of mod_mem_cache.
>>
>
> By the way, in your test case with 500-byte files, were the connections
> keep-alive?  If so, do you see better results with files >8KB (which 
> don't
> suffer from the known performance problem in core_output_filter)? 


Never mind, I suddenly realized that that's what you meant
by hacking the pipeline optimization code.

--Brian

Committed ap_init_filter_func code

[Justin Erenkrantz]

On Fri, Jun 28, 2002 at 08:40:25AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz2002/06/28 01:40:25
> 
>   Modified:.CHANGES

>   Log:
>   Add a filter_init function to the filters so that a filter can execute
>   arbitrary code before the handlers are invoked.

I went and committed this as no one has suggested a *viable*
alternative to this approach that doesn't have design flaws.

I know Greg is uneasy with this approach, but perhaps now that it is
in the repository, it'll spark him to come up with an approach that
is better.  

The one caveat of the filter_init function is that it can not
play with the headers because the handlers are responsible for
setting the headers (such as L-M and C-L...).  If/when we revamp
handlers again, perhaps it would be nice to separate out the headers
from the entity generation (i.e. two distinct phases) - so that this
filter initialization could execute once the headers are set in
stone but before the content is created.  I don't think we could do
this in a 2.0 construct, so this might be something to add for a 2.1
(or 3.0).  NBD in any case.  -- justin