mod_include Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Brian Pane <bp...@pacbell.net>]

  Graham Leggett wrote:

>Bill Stoddard wrote:
>
>>Yep, you definitely need CACHE_OUT to be a CONTENT filter in this case since INCLUDES is a
>>CONTENT filter and you need INCLUDES to be run after CACHE_OUT.
>>
>
>I disagree - includes is something that should be cached as it is a
>performance bottleneck.
>
Yes, include processing is a performance bottleneck.  But some of us are
trying to fix that. :-)

mod_include's slowness is due mostly to implementation details, rather
than any fundamental architectural limitations.  For example, it's not
uncommon for mod_include to spend a third of its execution time setting
environment variables that are never read.

The two patches that I recently posted (one for the environment variable
code, the other for the code that splits buckets if the buffered data
is too large) should help streamline mod_include so that it spends most
of its time doing what one would expect: scanning the content to look
for SSI directives.

In addition, Ian is working on improvements to the parser logic itself--
e.g., scanning every 5th character, rather than every character, when
looking for a '<!--#' token.

Collectively, these changes should help bring the speed of parsed requests
closer to the speed of unparsed requests.

--Brian