From: "Brian Pane" <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 8:59 PM
> William A. Rowe, Jr. wrote:
> [...]
>
> >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?
> >
> I've definitely focused just on the static preconstruction
> approach, and I've specifically avoided the dynamic caching
> approach. Here's my rationale:
>
> 1. I'm not convinced that the dynamic caching technique can
> be implemented without creating a scalability problem (due
> to the need for mutexes around the cache).
Agreed [to the mutex] - dunno if we can effect some scalability in any case by
not locking the table for the duration of the update, but just for the invalidate
- validate toggle. I suppose we would have to force another thread to lock while
we finish constructing a given node on the cache, thought.
> 2. From a return-on-investment perspective, the static cache
> looks a lot more appealing than the dynamic cache. I.e., I
> anticipate that a static cache will offer 80% of the performance
> benefit of a dynamic one for 20% of the development cost. (In
> particular, a static cache is a *lot* cheaper to test, because
> it's not vulnerable to the race conditions that make a dynamic
> cache tricky.)
Agreed that this is simple to validate. I'll take some time to look at it, but
I (imagine) that the tree walking *could* become a nightmare. I tend to think
in terms of caching all cited <Directory> blocks, Alias targets, etc, which the
user has identified with Override None.
Could we implement your cache on an explicit - rather than tree-walking basis?
I would think an info level warning that a given directory/alias could not be
cached (due to AllowOverrides) would help the administrator troubleshoot their
performance questions.
Sound like a plan?
Bill
