[Koha-devel] using CHI directly to use all of it's advantages

[Dobrica Pavlinusic]

On Thu, Jun 14, 2012 at 03:23:59PM -0400, Jared Camins-Esakov wrote:
> > - very nice syntax:
> >
> > my $customer2 = $cache->compute($name2, "10 minutes", sub {
> >        get_customer_from_db($name2)
> > });
> >
> > Which I would prefer to our existing Koha::Cache API. It would also save
> > us quite a bit of code.
> 
> If we were to make CHI a core dependency, I see no reason not to have a
> Koha::Cache wrapper subclassing CHI so that if we had to globally adjust
> cache settings we could do so. We would use the exact same interface as
> that exposed by CHI but would be able to transparently handle Koha-specific
> creation options (e.g. any sysprefs for turning the caching on or off, or
> selecting a non-default backend).

This makes total sense. So, I can expose CHI's ->compute method through
Koha::Cache wrapper and use it that way.

This might even bring us additional benefit of caching for OPAC and not
caching for Intranet for example :-)

> > CHI has powerfull statistics which basically obsolete my idea of writing
> > statistics gathering code through Koha.
> >
> > I would love to have this in next release, since this is more-or-less my
> > last major gripe with current Koha code (short-term goal[1]), so if I
> > would love to hear feedback.
> >
> > 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177
> >
> > My more long-term goal is to know more about Koha's data-access
> > patterns (you are again advised to examine performance wiki page if you
> > haven't up to this point).
> >
> > In most simple sense, only think which is big unknown is wheater we can
> > find sane key namespace schema which will allow us to good-enough cache
> > invalidation scheme. I strongly think that time-outs are useful just for
> > OPAC, not for intranet use!
> 
> This is why I do not think memoize is a good idea. Useful cache
> invalidation with memoize -- at least as I read the code implementing the
> memoize function -- is impossible. Using compute around a method call would
> be a much better option. If you want to make it appear seamless without
> modifying the underlying function, do the computation in a private method
> and surround a call to that with commute in a routine that does nothing
> other than run the compute (or invalidate the cache if that is what is
> desired).

I look at memoize as a easy way to find our which parts of our data
model should be cached. Once we find contended places, we can remove
memoize and implement proper compute for that part of code.

It's more development help than long-term solution.

> +1 from me on making CHI a core dependency.
> -1 on decentralizing cache access with memoize and direct 'use CHI'
> throughout the Koha/C4 namespace
> +1 on making Koha::Cache a transparent wrapper around CHI and using compute
> instead of the existing get/set whenever possible
> 
> In summary, I almost entirely agree with you, and would sign off on a patch
> changing our caching to CHI only provided it kept the code that interfaces
> directly with CHI neatly cordoned off from the rest of the system.

+1 from me about this one.

> P.S. If we need to replace the SQL query cache with a local cache, doesn't
> this mean we're doing it wrong?

Sure, but it's low-hanging fruit, and this is currently a huge
show-stopper if you want to have MySQL on another machine since network
latency is killing our performance.

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin