Le 06/04/2012 12:40, Chris Cormack a écrit :
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. Agreed, I have missed this option !
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. I think I don't understand what you mean here.
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. So how should we do to reduce the load caused by the repeated SQL queries for systempreferences, languages, itemtypes, patron categories,... ?
You think we should use something that is not caching ? You suggest memcache caching for complex things and another method for "simple" queries ? which method ? Could it be an option to build dynamically a perl file that contains, for example, a hash with all sysprefs, that is loaded through a use Koha::Cache::Sysprefs; Koha::Cache::Sysprefs.pm being my $syspref = { 'IndependantBranche' => 0, 'LibraryName'=> "my library", ...} that is just build automatically, and only once ? Aren't the sysprefs and some other parameters stable enough to accept flushing Plack threads when something is changed ? (I'm not sure at all this idea is good, just want to avoid missing something interesting ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08