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 [email protected] Unix addict. Internet consultant. http://www.rot13.org/~dpavlin _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
