[Rt-devel] SearchBuilder::Record::Cacheable study and call for comments

Jesse Vincent jesse at bestpractical.com
Wed Jun 16 12:14:09 EDT 2004

On Wed, Jun 16, 2004 at 10:01:54AM -0500, Matt Knopp wrote:
> Incidently I've been thinking about making a new Cacheable. 

[For those playing the home game, Matt wrote SB::R::Cachable in the
 first place]

> Limiting the lifespan of the cache to a single request is one good 
> way to make Cacheable better. Though off the top of my head I'm 
> thinking it'll be fairly hard to refactor Cacheable to do that. I 
> think you'll basically have to rewrite it, or you could cheat and 
> clobber both of it's global stores.

Adding an method to explicitly clear both global stores is very doable.
It's something that I've talked about with a number of folks over the
past couple years, but we haven't seen hard numbers suggesting that
clearing the whole cache per request was really the right thing to do. 
(If you've got those hard numbers, I'd love to see them.)  

> So the new Cacheable I've been thinking about would use 'memcached' 
> rather then trying to do it's own thing. One of the major perks of 
> using 'memcached' is that the cache can be shared across any number 
> of processess/threads/servers. 

*nod* memcached does seem to be a big win here. My only concern is that
everything work reasonably well in the fallback case when there's no
memcached to use.  I'll also note that memcached and its perl API come
with almost no tests, which doesn't give me a warm feeling about them.


More information about the Rt-devel mailing list