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

Frédéric Demians frederic at tamil.fr
Fri Apr 6 12:08:13 CEST 2012


Since Koha is a multi-threading app, with or without Plack, caching is
not that easy. There is already some caching but at thread level.
Memcached can be a solution for sharing cached data structure (like
framework for example) between threads, and even between threads running
on multiple servers. MySQL can even been used in place of memcached: we
replace multiple queries by one query to a MySQL 'cache' table.  If we
agree that multi-application-servers is not a requirement, other caching
solution are possible, in memory caching like Cache::FastMmap for
example.

SQL queries optimization is another issue. If data structures requiring
a lot of SQL queries to be build are cached, we don't care that much if
those queries are all but perfect. Of course, we still can focus on
optimizing other SQL queries: on biblios/items, etc.

Dobrica Koha::Persistant module make sense to me. It has thread
in-memory caching now, but can be extended to implement multi-thread
in-memory or in memcached (or redis, MySQL...) caching. The question is
more: is it necessary to mix caching and SQL querying? Isn't it too much
or too complex? The key in Dobrica cache is calculated based on query
parameters: is it robust enough?  There is also a coming issue to solve
when caching will be done in multi-threading: the data structure will
have to be deserialized when getting it, or serialized when put in cache
(storable, something else). To avoid having to get & deserialize data,
again and again, we can have a two level caching, in thread memory, and
in-memcached, but then the invalidation issue come back...

My limited thoughts...

-- 
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html



More information about the Koha-devel mailing list