----- Original Message -----
From: "Brian Pane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 6:45 PM
Subject: [PATCH] pre-merge of per-dir configs to speed up directory_walk
> This is an updated version of a patch that I posted a while back. I've
> cleaned up my code a bit and modified it to work with the latest version
> of mod_include.
>
> This patch attempts to pre-merge all of the non-regex, non-.htaccess
> per-directory configuration structures at server startup, so that
> directory_walk can use the pre-merged values. The motivation for
> this is to eliminate expensive dir_merge functions during request
> processing.
This leaves a big hole in the .htaccess schema.
I'd suggest we begin pursuing a caching schema, instead of a 'preconstruct'.
Provided specific parameters for the cache (similar to the args to your pre
construction code), and some timeout values, we can entrust the walk to do
the 'right thing'. I'd like to see the cache list n*3 larger than the cache
itself, to allow entries to 'fall into' cached space, and 'fall back out'
so we don't have req=1 contention in the cache space.
The cache itself can be a descendent of the server config pool. The children
can be derived from the 'nearest descendent' so we don't over-construct. The
cache needs to be refcounted by request, so we can free individual cache
entries, and their parents (the cache must be walked backwards for destruction
when the entry expires.) If a parent expires, it's removed from the cache
match list, but not freed until all it's descendents are freed (when it is
staled, it should walk its descendents expiring them all.)
I'd suggest the child timeouts inherit;
immortal, if all parents and the child disallow .htaccess sections.
timed, if it allows an .htaccess
allowed to be 'renewed' if the .htaccess was not updated.
and children ignore their parent timeout critera, the child may be immortal,
but if the parent has a timeout and expires, it will timeout the children.
This is just a theory, but I'd like us to go further with building pre-merged
sections that can just be merged to a volatile section as a group. So if the
bar/bing/bong directories '/foo/bar/bing/bong' all disallow htaccess, but foo
allows it, bong would have a preconstructed bar/bing/bong that will _never_
change (could be flushed if there were insufficient requests), but a volatle
merger of /foo to that merged set.
About your patch - if it goes in this direction (I simply skimmed it so far)
then I'd be happy to apply, but it looks like we are trying to accomplish two
different things. Since the broader 'dynamic cache' schema is where we want
to end up (IMHO) and will invalidate the usefulness of an additional 'static
cache' (preconstructed at boot time), I'd like to pursue one chunk of code
that everyone can focus energy at, rather than two sets of code with their own
debugging cycles. Of course, I could be entirely off base.
What are your thoughts on these two different strategies?
Bill
