[Koha-devel] RFC: Koha::Persistent - for plack and general performance

Chris Cormack chris at bigballofwax.co.nz
Fri Apr 6 12:40:32 CEST 2012


>
> As you're experimented in caching, a question: I think cache
> invalidation can be made by 2 different techniques:
> * when a data make the cache invalid, it send a message to all cache to
> say "hey, cache is reseted". Cache is reseted, and next time a data is
> requested it won't be in the cache.
> * when a data make the cache invalid, it just set a flag saying "the
> cache is invalid", and everytime a data is requested, the cache handler
> check if the cache must be reseted, and if it must, reset and re-load
> the real data.
>
> Am I right if I say that the 1st technique is the best and is what is
> achieved by ->flush_cache() method of (memoize::)memcached ?

The third option, and best option imho is when a value is change, it
is injected into the cache at that point. The second best option is to
remove the object from the cache (option 1) Frederic is right, the big
when is in caching serialised objects, not sql results, things like
the rdbms and DBD::Gofer cache sql results well.

>
> Other question: I see in memcached that the server can be
> /var/sock/memcached. Is it possible that it would be faster than a full
> IP addresse (for libraries that would have the memcache server on the
> same server as the Koha server) ?

Could be, but like I was saying we shouldn't be using memcached (or
application level caching) for simple sql queries, we should be
caching the things that either are slow queries or are the result of a
lot of queries. We should be caching processed results, things that
are computational expensive to generate. Also redis seems to be the
clear leader in key-value stores now, we should definitely investigate
that more.

Chris


More information about the Koha-devel mailing list