I'm again beginning to look at performance issues of clusters and determine where gains can be made. It's good that string cache (MDL-41019) have been included. However having a central store for that means that I am seeing 100-700 calls to MUC during a page load just for strings. With network overhead of shared storage, that can add up to 700ms to a page load time.
The creation of localcachedir was a great step in the direction of speeding up accesses. There is then the wiki page https://docs.moodle.org/25/en/Caching#Cache_definition_configuration which describes the different core caches and whether they need to be local or shared. I have spent quite some time reading and working on the MUC code and the idea of having to understand which caches could be configured locally or not it's still very much out of my league of understanding.
With the above in mind and Petr's original proposal to add the ability to use localcache for revision based systems, I'd like to discuss options for progressing that forward. Particularly for some caches like string and database metadata.
Things I've thought about so far;
1. Add a revision tag to the loader class in MUC as well as a definition item for revisions. If those are set by the developer, you don't get to configure the cache in MUC, it's automatically a localcache but the API for MUC users is the basically the same. Just a requirement to set a revision before get/set.
2. Do the items in 1, but also add the data to a shared storage as a backup cache if local doesn't have it. If it's expensive to build the cache then this addition may be helpful to warm a cache in a new node without too much user impact.
3. Upgrade the file cachestore to be the backend for all the local caches, so it uses all the same mechansims as other caches and is well tested. This would just require detection that it's a localcache to ensure the directory is created in the correct location.
With those in place, any cache with a revision flag, either at the cache or key level would be able to move to local. I believe this would have a performance improvement on networked clusters without any impact on single server installations. Immediate candidates appear to be stringcache, langcache, database-meta and course_modinfo.
I would appreciate any feedback and further ideas before I push any further ahead with development in this area.