Caching

A cache is a collection of processed data that is kept on hand and re-used in order to avoid costly repeated database queries.

Moodle 2.4 saw the implementation of MUC, the Moodle Universal Cache. This new system allows certain functions of Moodle (eg string fetching) take advantage of different installed cache services (eg files, ram, memcached).

In future versions of Moodle we will continue expanding the number of Moodle functions that use MUC, which will continue improving performance, but you can already start using it to improve your site.

General approach to performance testing

Here is the general strategy you should be taking:

1. Build a test environment that is as close to your real production instance as possible (eg hardware, software, networking, etc)
2. Make sure to remove as many uncontrolled variables as you can from this environment (eg other services)
3. Use a tool to place a realistic, but simulated and repeatable load upon you server. (eg jmeter or selenium).
4. Decide on a way to measure performance of the server by capturing data (ram, load, time taken, etc)
5. Run your load and measure a baseline performance result.
6. Change one variable at a time, and re-run the load to see if performance gets better or worse. Repeat as necessary.
7. When you discover settings that result in a consistent performance improvement, apply to your production site.

How to use the caching settings

Since Moodle 2.4, Moodle has provided a caching plugin framework to give administrators the ability to control where Moodle stores cached data. For most Moodle sites the default configuration should be sufficient and it is not necessary to change the configuration. For larger Moodle sites with multiple servers, administrators may wish to use memcached, mongodb or other systems to store cache data. The cache plugin screen provides administrators with the ability to configure what cache data is stored where.

Types of cache

Moodle uses three types of cache to store cached data:

• Request cache - The request cache is available for the duration of every page request. It is not shared between users and is used and cleared on every Moodle request.
• Session cache - The session cache is available through a users session in Moodle. It is not shared between users, but persists for a single user throughout their session (i.e. from when they logon til when they log off)
• Application cache - The application cache is a shared cache which is available for every request. It can be shared between users and the cached data can be kept indefinitely if required.

Cache types and multiple-server systems

If you have a system with multiple front-end web servers, the application cache must be shared between the servers. In other words, you cannot use fast local storage for the application cache, but must use shared storage or some other form of shared cache such as a shared memcache.

The same applies to session cache, unless you use a 'sticky sessions' mechanism to ensure that within a session, users always access the same front-end server.

Installed cache stores

This section of the administrator screen displays cache plugins which are installed on the system. It lists what the capabilities of each plugin, what type of cache they provide and provides allows a cache store to be added to the system.

Configured store instances

This section of the administrator screen displays cache stores which have been added to the system. It gives the ability to change the cache configuration and purge the cached data.

Cache lock instances

Moodle supports different mechanisms for 'locking' access to the various cache stores. At present there is only one option and it is not used, so it can safely be ignored.

Known cache definitions

Known cache definitions displays the caches which are in use by Moodle. Each item is an area of Moodle which is using caching. It gives the administrator the ability to configure an individual area of Moodle to use a different cache backend. For example, an administrator of a Moodle cluster may choose to make language string definitions be cached on a dedicated memcached server by using the memcached cache backend. See the section below for more information about configuring these.

Cache definition configuration

Each different cache can be configured independently, allowing admins to "tune" their setup for particular systems.

By default these caches are all set to use files, which is usually fine on a small one-server system.

On a cluster, however, these defaults can cause problems because shared filesystems are slow, so in these cases we recommend you use a faster shared caching backend like memcached instead. Note that most of these caches operating under the assumption that they are shared.

In some cases you can choose to use a non-shared cache like the local filesystem however in these instances you be careful to purge caches MANUALLY as part of system administration.

The following reference is intended to help you understand how each caching definition works so you can tune appropriately:

(Note to doc editors, we need contributions below:)

Language string cache

This is a cache of calculated strings which are originally pulled from language files.

In Moodle 2.5, this

• expects shared cache
• if not shared, must be manually purged after any language string change such as editing of local lang packs, updating of lang packs during upgrade, installation or uninstallation of languages

In Moodle 2.6 and later, this

• works fine with local or shared node caches, you don't have to do anything special.

Database meta information

This is a cache of database structure information.

• requires shared cache
• if not shared, caches need to be invalidated after any DB structure change including creation of temporary tables

Event invalidation

This cache is used to manage event invalidation.

• Whenever something is invalidated, it is purged immediately and an event record is created with the timestamp.
• Requires shared cache.

Question definitions

This cache is used by question bank and stores questions.

• This gets updated when question is loaded or edited.
• Doesn't require data guarantee.
• Requires shared cache.

HTML Purifier - cleaned content

This is a cache of texts (forum posts, resources, intros etc etc) from all parts of Moodle, after it has been cleaned of possible malicious data.

In Moodle 2.5,

• this expects a shared cache
• if not shared, must be manually purged after every upgrade or change of $CFG->allowobjectembed setting

In Moodle 2.6 and later,

• this works fine with local or shared node caches, you don't have to do anything special.

Config settings

This is used for storing data of config and config_plugins database table.

• This cache is hit quite often for getting config settings.
• Requires shared cache.

Course group information

This cache stores groups and groupings data belonging to a course.

• Gets updated when groups data is fetched for a course.
• Requires shared cache.

Calendar subscriptions

• What is cached:- Record entries from 'event_subscriptions' table, representing various calendar subscriptions.
• When the cache is updated:- When a calendar subscription is updated or deleted.
• How often it is hit:- Everytime a calendar subscription detail is fetched.
• When should the cache be purged completely:- This should not be needed.

YUI Module definitions

This stores the YUI module metadata for Shifted YUI modules in Moodle.

• Serves YUI module metadata, when JS caching is enabled.
• Requires shared cache.

Event observers

Introduced in 2.6

This cache is used for storing list of event observers.

• It is updated on install/update while initialising list of event observers.
• This cache is accessed, when event is trigged.
• Requires shared cache.

Plugin info - base

This cache is used by plugininfo_base class and stores plugin information.

• This is accessed while loading/checking plugin versions from disk.
• Requires shared cache.

Plugin info - activity modules

This cache is used by plugininfo_mod class and provide access to records in modules table.

• This is accessed while loading/checking modules.
• Requires shared cache.

Plugin info - blocks

This cache is used by plugininfo_block class and provide access to records in block table.

• This is accessed while loading/checking blocks.
• Requires shared cache.

Plugin info - filters

This cache is used by plugininfo_filter class and stores names of all filters installed.

• This is accessed while loading/checking installed filters.
• Requires shared cache.

Plugin info - repositories

This cache is used by plugininfo_repositories class and provide access to records in repository table.

• This is accessed while loading enabled repositories.
• Requires shared cache.

Plugin info - portfolios

This cache is used by plugininfo_portfolio class and stores list of enabled portfolio plugins.

• This is accessed while checking if portfolio is enabled.
• Requires shared cache.

Course categories tree

This cache is used to store the full tree of course categories

• It is accessed while rendering or managing course category.
• Gets invalidated when changesincoursecat event is triggered.
• Requires shared cache.

Course categories lists for particular user

Used to store data for course categories visible to current user. Helps to browse list of categories

• It is accessed while rendering course category for a user.
• Is invalidated when changesincoursecat or changesincourse event is trigged.
• Requires shared cache.

Course categories records

This cache is used to store course category object, with record of data in course_categories table

• This is accessed while rendering course category
• Is invalidated when changesincoursecat event is triggered.
• Require local cache

List of course contacts

This cache stores contacts for the courses

• This is accessed while rendering/searching course
• Requires shared cache.

Repositories instances data

This cache is used to store data for repositories to avoid repetitive DB queries within one request

Stores used when no mapping is present

This section displays the default cache stores which should be used by Moodle for each type of Moodle cache. If a mapping for a cache definition does not exist then this default store will be used instead.

Other performance testing

Two links that might be useful to anyone considering testing performance on their own servers:

• Moodle performance testing: how much more horsepower do each new versions of Moodle require?
• How to load test your Moodle server using Loadstorm

Other performance advice for load-balanced web servers

1. In Moodle 2.4 onwards with load-balanced web servers, don't use the default caching option that stores the data in moodledata on a shared network drive. Use memcached instead. See Tim Hunt's article on http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html
2. In Moodle 2.6 onwards make sure you set $CFG->localcachedir to some local directory in config.php (for each node). This will speed up some of the disk caching that happens outside of MUC, such as themes, javascript, libraries etc.

See also

Using Moodle forum discussions:

• MUC is here, now what?
• Status of MUC?
• Putting cachedir on local disks in cluster
• moodle cachestore_file

Developer documentation:

• dev:The Moodle Universal Cache (MUC)
• dev:Cache API
• dev:Cache API - Quick reference

Other:

• Moodle 2.4.5 vs. 2.5.1 performance and MUC APC cache store blog post by Justin Filip