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

[Dobrica Pavlinusic]

I would like to propose new module which would keep track of all
persistant values for rest of Koha code.

We are currently using following caching strategies:

1. our $cache variables
2. memoize (in-memory)
3. memoize_memcache (in memcache only)

As opposed to C4::Cache* which never got implemented in all code,
I propose new Koha::Persistant[1] module which provides methods for caching
designed in such a way to reduce code size in modules which use it,
see [2] for authorised_value and [3] for marc_subfield_structure

1: https://github.com/dpavlin/Koha/blob/plack/Koha/Persistant.pm
2: https://github.com/dpavlin/Koha/commit/6cd524f99b1bbc03eb1ad7110b0b97016569387d
3: https://github.com/dpavlin/Koha/commit/70a414d93bd0ae309e9d6097ea87a17e3341fe3c

I implemented just two function to see if this approach makes sense. I
started with DBI Profile to track down same or similar queries and try
to make nice API which satisfies requirements above.

It also provides $Koha::persistant::stats which can be used to track
hit/miss ratio of cache so we can easily evaluate caching impact.
There is even Plack development panel, see "Persistant" at 1:01-1:30
http://blog.rot13.org/koha/koha-plack-debug.ogv

Koha::Persistant should also include invalidation functions for all
structures which it addresses, so they can be inserted in corresponding
places to provide correct values when changing data directly in
database. This will be done for existing functions before I submit it to
Koha to keep everything clean from the start.

It would also provide memoize function, which would replace
memoize_memcahe and provide in-memory caching together with memcache,
but still cache in memory if memcache isn't available. As shown in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7879
we do get performance benefit from it, since our code is using
MySQL query cache a lot which means we are quering for same data
over and over again, see:
http://wiki.koha-community.org/wiki/Performance#MySQL_tuning

In first phase, I would propose to reset in-memory cache and memoize
functions on each request to be consistant with CGI implementation and
side-step caching bugs which we see with plack right now.

This style of implementation will require large patches which touch many
different places of code at same time. I think that 3.10 relese cycle is
good way to introduce this changes, but I would need commitment from
developers to Sign-off and QA patches fast, since those changes will be
hard to keep up with development.

p.s. I will create RFC wiki page after discussion, but I would really need
some response before continuing down this path.

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