I've done some testing of this on a big, complex search results page with data from one of our largest partners, and have seen some immediate benefits. One optimization that seems to make a big difference for Plack, though, is less-frequent clearing of the L1 cache. I'll be attaching a POC later today, but the basic idea is to store an modification time in memcached whenever a cache value is set and check that time before returning a value from the L1 cache. If memcache has been modified more recently than the L1 cache, the L1 is cleared. This means that each Plack worker process can have its own persistent L1 cache but clear it only when it becomes stale. Some timing numbers to support this (the test page is a search results page with 50 results and XSLT): Before any caching at all, the page took 30 seconds (!) to load. With memcached sysprefs: ~9 seconds With an L1 cache cleared before every request: ~8.5 seconds With an L1 cache cleared only when memcache is modified: 7 seconds I expected the roundtrip to check the memcache modification time on every cache lookup to cancel out the gain of the L1, but as seen above, this is clearly not true. Any ideas about a better implementation are of course welcomed. 2016-03-11 11:33 GMT-07:00 Tomas Cohen Arazi <tomascohen@gmail.com>:

Hi

2016-03-11 10:38 GMT-03:00 Jonathan Druart < jonathan.druart@bugs.koha-community.org>:

...

Hi devs,

I have worked on a three-level cache to cache our stuffs: L1 - hashref L2 - memcache L3 - DB

Please have a look at bug 11998 and bug 16044. I really really would like to get your opinions on these patches.

I really like the approach because it provides a specilized way of dealing with caching for each use case. Thus, no penalty because of the removal of in-memory cache (L1), and we can have proper invalidation for heavier stuff on memcache (L2) without the need to have a single way to cache stuff.

I signed 11988 after reviewing and properly testing it. The only issue I found was that it was sysprefs-specific, and then I found 16044 put the code were it belongs, and I can say we can find some bug on it, but this is a huge improvement in terms of speed and also maintainability.

Congrats Robin and Jonathan

-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/

-- Jesse Weaver