Food for though... With Plack, we are in a persistent environment. It means we can keep Koha configuration information in each thread. Config info are all data that doesn't change that much and are not too large (like biblio catalog). In each thread, at startup, loading configuration data is required. In Koha: frameworks, authorized_values, item types, branches, etc. It implies a lot of SQL requests. If we have a application-level cache, rather than loading info from DB or config files (koha-conf.xml XML parsing), we can get them from the global cache (memcached, redis, MySQL based, in-memory, etc.). A key/value cache doesn't handle Perl native data type. So it means that data has to be deserialized. It consumes CPU, less than getting data from DB/config files, but still. So in a persistent environment, we should try to avoid that, and cache locally, in each thread, configuration data. We have something like in this schema: thread-1 thread-2 thread-n | | | local local local cache cache cache ( | ) \ | / \ | / +--- application----+ cache | DB or config files So if thread-2 modify something in its local cache, it can cascading update application cache and DB / config files. The difficulty is to notify other threads to update their local cache. The question is: is there such a mechanism in Plack? I don't think so. Another solution could be to define a configurable timeout for each task. Every n seconds, the thread is restarted. Or we can have directly in Koha a timer which force reloading local cache. In both cases, the timeout can be adjusted. About the application cache, we may take a look at CHI module which seem to be standard, and allow to switch easily cache repository and cache serializer. -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html