Caching

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.4. Up-to-date documentation for the latest stable version of Moodle may be available here: Caching.

New feature
in Moodle 2.4!


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.

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.

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:

Performance advise for Moodle 2.4 with load-balanced web servers

Performance advice: if you are running Moodle 2.4 with load-balanced web servers, don't use the default caching option that stores the data in moodledata on a shared network drive. Use memcache instead. See Tim Hunt's article on http://planet.moodle.org/ for 02 May 2013.

See also

Using Moodle forum discussions:

Developer documentation: