forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Locationmap Caching Help (FOR-732/711)
Date Thu, 30 Mar 2006 16:43:45 GMT
Tim Williams wrote:
> I've been looking into FOR-711 [1]/FOR-732 [2] and I'm in need of some
> new thoughts on the subject.  My "fix" for FOR-732 (changes to
> locationmap having no effect) has effectively reversed much of the
> benefit of caching the responses to begin with.  I'll explain...

Sorry for not responding sooner, I've been trying to find the time to do 
so properly. I'm not finding any time at the moment, so I'll just give 
an "off the top of my head" response, in the hope that it helps in some 
small way.

> The highlights of what I've done:
> o) Created isValid() on AbstractNode.
> o) Implemented isValid() on each node as appropriate.
> o) LocationMapModule now tests whether caching is turned on &&
> isValid() before returning a cached result.
> o) If the traversed isValid() returns an invalid result back to the
> Locationmapmodule, the cache is flushed.
> 
> The results I'm seeing: Slow, but the correct behavior... did I
> mention slow [3]?

Hmmm... that's quite a performance hit. I don't really understand why it 
is so bad with caching turned on. It's probably a really stupid question 
but are we using the right kind of data structure for the cache data.

One other thought, are we checking all isValid() methods or just the one 
  for the file in which the cached data was found? There is no need to 
traverse the cache files *below* the one we currently use for giving a 
result.

> So what to do and what am I asking?   
 > ...  even if we were to
> implement our own store ... it seems to me it's the sheer number
> of accesses that's the issue rather than storage location.

...

>  Having a
> configurable timeout (so that validity tests are only done every X
> number of minutes) would help but seems ultra-hacky.  

Why hacky? Isn't it standard practice for a cache to have a configurable 
TTL, then you use that it to fine tune performance, adjusting the cache 
on different requrests.

> So I'm asking
> for new thoughts, ideas, suggestions for alternative approaches.

I'm moving nearer and nearer to needing two configurations for my 
Forrest projects. One for "in development" and one for "in production".

The in development version has profiling enabled, and would have caching 
enabled. The in product would have both turned off (although in a 
dynamic site we would need to leave caching on).

Ross

Mime
View raw message