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