The problem: Moodle has a large amount of cache complexity across various different layers.
Catalyst manages this complexity using a tool that maps caches of data (known as cache
definitions) to their respective data locations (known as cache stores). The various cache stores
that we employ are:
• ‘APCu’ which is an in memory cache within the PHP manager. This is very fast, but limited
in size, and it doesn’t perform well when it is full. This is also only useful for data that can
safely be duplicated between multiple web servers, without resulting in stale data or
desynchronisation of state.
• ‘Redis’ which is a remote key value store that is useful for bulk storage. This is a shared
cache, that is accessible for reads and writes between all webservers used for the application.
• ‘File’ is a standard file on disk which can be used to store data. We employ a cache on each
webserver for data that can be safely stored on multiple servers, and a cache on the shared
filesystem that is spread across all webservers. This is faster than Redis for small items, as
the IO latency is lower than the network latency, but performance gets worse as the cache
size grows.
Defintions are mapped to one or more stores as the primary, secondary and tertiary locations in
which the data is stored. We use a JSON configuration to map these definitions, using rules which
match conditions of the definition, and map it to a matching definition. An example of a productionlike configuration is detailed in the README of the caching tool here: https://github.com/catalyst/
moodle-tool_forcedcache#step-3-wire-up-the-configuration
As can be seen, we have specific rules for a few of the most used cache definitions in Moodle, but
most definitions are mapped to the empty rule, which binds to redis. The core problem is that we
don’t have a good metric to perform automated testing on any change to the configuration, and we
do not have any data on how to improve this configuration.
The task: We need a tool that can work with the forcedcache tool, which does 3 things.
1. Given a base configuration file, load it into the forcedcache tool.
2. Run a suite of tests against the moodle instance which load up and access the caches with a
large amount of data, and measure the performance of the provided configuration.
3. Automatically make a change to the JSON configuration, and rerun the tests. The tool
should continuously update and test the configuration, until there is no change that results in
better performance.
The majority of the work here will be in designing an adequate test suite that covers all of the core
caches in the moodle code. A list of these can be found in the Caching administration page here:
`cache/admin.php`. The main focus here is anything that has a component of ‘core’
To help guide the design, a list of the amount of cache accesses (both read and write) is displayed in
the footer of the moodle page when using debugging (which is enabled by default in capstonedocker).