data编程代写、代写Java，Python编程

日期：2022-10-26 07:29

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).