Cache definitions

This page contains information on the cache definitions within core. This information will likely be of most use to those administrators who are really trying to get the most out the caching system in Moodle. The information about each cache should help in deciding which backends to use for which definitions.

For small sites, or those running on a single server likely adopting a single backend such as memcache is going to give you an immediate performance boost.
However with a bit of planning and some careful mapping likely you can improve things further.

What you will find in this document

Each cache definition found within core will be under its own heading and will include a description of the cache.
As well as the name and description the following information will also be details:

Since: When this cache definition was first introduced into Moodle.
Component/Area: The code component this cache belongs to and the area (unique simple name) given to it.
Growth: Will state if this cache is expected to be of fixed size, or can be expected to grow as the site data grows. Perhaps some information on how the cache will grow.
Who: Which users can expect to benefit from the cache.
Priority: An indication of the anticipated cache use on a site. A value between 1 and 5. If the cache is of fixed size and is accessed expected to be utilised on every page it will be given a 5 for priority as it can be expected that assigning that cache to the fastest backend available would be the good idea. In contrast a priority of 1 would be given to a cache that is expected to grow quickly, is only accessed on specific pages, and only applies to some users (e.g. teachers, or the admin). This cache should be the least of your concerns when deciding upon how to implement caching on your site.

A note about cache configuration on large sites

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 the file system, 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.

Application caches

Application caches are shared caches.

Accumulated information about modules and sections for each course

Accumulated information about course modules, and sections used to print the course page as well as in calls to get_fast_modinfo().
This cache gets forcefully reset within rebuild_course_cache().

This is an excellent cache to optimise caching for on a production site.
It is accessed primarily for the course view page, and very frequently hit and often expensive page and it is utilised within get_fast_modinot() a function that is called often in Moodle when querying or displaying information on a course, section or activity.

Since: Moodle 2.6
Component/Area: core, coursemodinfo
Growth: exponential, the number of courses, sections within those courses, and activities within each section will determine the size of this cache.
Who: everyone. This cache isn't accessed on every page, however as its associated with courses you can expect its accces to still be high.
Priority: 4

Calendar subscriptions

Caches calendar subscriptions.
This is a very simple cache that stores the calendar subscription records from the database for quick, specific access.

This should be considered a low priority cache unless your users are likely to be creating many calendar subscriptions.
The actual data being stored is going to be very small, should you have lots of calendar subscriptions mapping this cache definition to a fast, but small backend would be ideal.

Since: Moodle 2.5
Component/Area: core, calendar_subscriptions
Growth: determined by the number of calendar subscriptsion created by users. Entirely dependent on your users.
Who: everyone who has a calendar subscript, on calendar pages, or pages where the calendar block is being displayed.
Priority: 1

Notes for advanced, multi-server sites

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

Concept linking [mod_glossary]

Caches concepts for the glossary filter.

Concepts are cached in relation to either the site or a course. The course ID is used as the key if they are for a course, 0 is used as the key for site concepts.
Each entry in the cache is an array consisting of two items, the first is an array of glossaries, the second an array of concepts.
The actual data being stored is minimal, even on a large site the storage requirement for this cache should be relatively small.

Important This cache CANNOT be a local cache, it must be shared.

Since: Moodle 2.7 (MDL-44366)
Component/Area: mod_glossary, concepts
Growth: exponential, the number of glossaries, and the number of terms within those glossaries will determine the size of this cache.
Who: everyone when the glossary filter is enabled.
Priority: 3

Config settings

Caches the configuration for the site. This is the administration settings in both core and all plugins.

This cache is going to be accessed on every single page within Moodle, regradless of the users state or what is being done.
You should map this cache to the fastest backend you've got available.

Since: Moodle 2.4
Component/Area: core, config
Growth: fixed, the number of items is the number of settings in core and all installed plugins. This will only increase as settings are introduced or removed.
Who: everyone, on every page, without fail.
Priority: 5

Notes for advanced, multi-server sites

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

Course categories tree

This cache stores the full course categories tree.

It is often used when navigating the course category structure and you can expect it to be hit in situations where either the full tree, or part of the tree is displayed.
This includes some elements that can be configured to display on the front page.
Its use will be determinent on how you have configured Moodle and what is set to be displayed.

Since: Moodle 2.5 (MDL-38147)
Component/Area: core, coursecattree
Growth: fixed, will be limited to the number of course categories on your site. During course creation this site will obviously grow, but in day to day use it should remain static.
Who: everyone.
Priority: 3

Notes for advanced, multi-server sites

• Requires shared cache.
• Gets invalidated when changesincoursecat event is triggered.

Course group information

Caches grouping information for courses.

Information is cached in relation to a course and is very simple. It is only used in situations where a course has defined groups and those groups are being used.
This cache can be expected to save 1 - 2 queries per page.

Since: Moodle 2.5 (MDL-34398)
Component/Area: core, groupdata
Growth: fixed, the number of courses and groups within those courses determines the size of this cache.
Who: all users accessing a course in which groups are used.
Priority: 2

Notes for advanced, multi-server sites

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

Database meta information

Caches meta information on database tables including information about columns.

This cache is a priority cache, it is accessed on nearly every page within Moodle and its operation can be expensive.
Each entry uses the table name as the key and the cached data is the structure of the database table.

Since: Moodle 2.4 (MDL-25290)
Component/Area: core, databasemeta
Growth: fixed, the number of database tables determines the size of this cache and may only change during upgrade and installation/deletion of plugins.
Who: everyone
Priority: 5

Notes for advanced, multi-server sites

• 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 for the MUC API. This is an internal API and has no relation what so ever to the Event API introduced in 2.7.

This is not often used within Moodle and when it is used occurs when editing happens and multiple caches need to purged, not all of which may be shared and some which may be cleared when the user next touches the cache. The overall cache size should be relatively small, and as checking often occurs for these caches on page access it is recommended to map this cache to a fast backend.

Since: Moodle 2.4 (MDL-25290)
Component/Area: core, eventinvalidation
Growth: fixed, events are subscribed to by definitinos and will only change during upgrade and the installation and deletion of plugins.
Who: everyone, events get triggered by action and in disconnected caches this be not be reflected until the user next hits the page.
Priority: 4

Notes for advanced, multi-server sites

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

Event observers

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.

Since: Moodle 2.6 (MDL-39846)
Component/Area: core, observers
Growth: ?
Who: ?
Priority: ?

Notes for advanced, multi-server sites

• Requires shared cache.

External badges for particular user

Used to store external badges.

Since: Moodle 2.5.2, 2.6 (MDL-40924)
Component/Area: core, externalbadges
Growth: ?
Who: ?
Priority: ?

Grade items cached for evaluating conditional availability [availability_grade, items]

Used to cache course grade items for conditional availability purposes.

Note: This cache sets a TTL (Time To Live) of 3600 (1 hour).

Since: Moodle 2.7 (MDL-44070)
Component/Area: availability_grade, items
Growth: ?
Who: ?
Priority: ?

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.

Caches cleaned text in relation to user + context of the text being cleaned.

Tip: This data may be safetly stored in local caches on clusted nodes.

Since: Moodle 2.4.2, 2.5 (MDL-36297)
Component/Area: core, htmlpurifier
Growth: exponential, cleaned content is usually stored once for each user + context combination.
Who: everyone
Priority: 3

Notes for advanced, multi-server sites

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.

Language string cache

The language string cache is one of the most essential caches within Moodle, it caches each and every language file used within Moodle.
Its of fixed size as there are a finite number of languages and language files and as it is accessed one pretty much every page within Moodle.
This is a prime cache to configure, map it to the fastest backend you've got available.

The string cache uses the a hash of the revision, language, and component of a language file as the key, and the array found within the corrosponding file is the data.
Static acceleration is used on this cache to speed up subsequent request for a string within a given language file. This is essential as string are usually requested one by one and often only from a handful of language files.

Tip: Cache usage differs greatly between Admins + managers and teacher + students. Admins and managers being able to complete more actions and often across difference components and plugins often require that many more language files be accessed for a page than a user such as a teacher or student require.
When testing your cache configuration ensure you test as a student.

Since: Moodle 2.4 (MDL-25290)
Component/Area: core, string
Growth: fixed size, each language string file is cached here, its size will be fixed but will be determined by the number of languages available on your site.
Who: everyone, on every browsable page within Moodle.
Priority: 5

Notes for advanced, multi-server sites

• If shared between sites please be aware that any language customisations will also be shared.

In Moodle 2.4 and Moodle 2.6:

• Expects shared cache.
• If not shared it 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:

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

List of available languages

Caches a list of available languages.

This list of languages is used every time the list of languages is requested in a page.
Because of this the cache will be hit by on many pages within Moodle on any site with more than one language installed. As its a small, fixed size cache on a site with multiple languages installed its a good idea to map this to the fastest backend you've got available.

Since: Moodle 2.6 (MDL-41019)
Component/Area: core, langmenu
Growth: fixed, determined by the number of languages installed on the site.
Who: everyone
Priority: 4

List of course contacts

Used to cache course contacts.

Course contacts are displayed in several places throughout Moodle, they are in most situations considered public information (like course names) and can be seeing by all users.
The process of listing these course contacts can be expensive, however the course contacts are shown only on select pages.

Since: Moodle 2.5 (MDL-38596)
Component/Area: core, coursecontacts
Growth: the number of courses and the number of users with course contact roles determines this size of this cache.
Who: everyone, course contacts are public information and may be displayed in several places throughout Moodle that can be accessed by anyone.
Priority: 3

Notes for advanced, multi-server sites

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

Plugin info manager

Caches information on installed plugins, enabled plugins, and present plugins.

This cache is heavily used when managing plugins for site through the admin interfaces.
Primarily people accessing this page benefit from the existence of this cache.

Note: This must be a shared cache.

Since: Moodle 2.5 (MDL-34401)
Component/Area: core, plugin_manager
Growth: fixed, the number of plugins determines the size of this cache.
Who: Administrators primarily.
Priority: 2

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.

Question definitions

Caches question definitions. This is used by the question bank class.

Since: Moodle 2.4 (MDL-34399)
Component/Area: core, questiondata
Growth: ?
Who: ?
Priority: ?

Notes for advanced, multi-server sites

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

User grades cached for evaluating conditional availability

Since:
Component/Area: core, gradecondition
Growth:
Who:
Priority:

User grades cached for evaluating conditional availability [availability_grade, scores]

Used to cache user grades for conditional availability purposes.

Note: This cache sets a TTL (Time To Live) of 3600 (1 hour).

Since: Moodle 2.7 (MDL-44070)
Component/Area: availability, scores
Growth: ?
Who: ?
Priority: ?

YUI Module definitions

Caches information on shifter YUI modules used within Moodle when JS caching is enabled.

Since: Moodle 2.5 (MDL-38391)
Component/Area: core, yuimodules
Growth: fixes, the number of Moodle YUI modules within core and plugins. This will only change during upgrade, or installation/removal of plugins.
Who: everyone, this is used when ever Moodle YUI modules are used on a page and that is most pages as of 2.8.
Priority: 5

Notes for advanced, multi-server sites

• Requires shared cache.

Session caches

Data cached here belongs to the user browsing the site.

Course categories lists for particular user

Used to store data for course categories visible to current user. Helps to browse list of categories.
This is also used during course category management.

Since: Moodle 2.5 (MDL-38147)
Component/Area: core, coursecat
Growth: the number of categories and courses on the site that the user can see will determine the size of this for the current user.
Who: everyone, it is used within several front page elements.

Notes for advanced, multi-server sites

• Requires shared cache.
• Is invalidated when changesincoursecat or changesincourse event is trigged.

Data used to persist user selections throughout Moodle

Caches user selections that should persist for the lifetime of the users log in. This includes things like which categories the user has expanded in the course category management page.
Think of them like user preferences but with limited lifetime.

Since: Moodle 2.6 (MDL-42299)
Component/Area: core, userselections
Growth: exponential, depends upon how much the user interacts with things like expading categories.
Who: logged in users.

Folder name cache [repository_skydrive]

?

Since: Moodle 2.6 (MDL-30740)
Component/Area: repository_skydrive, foldername
Growth: ?
Who: ?
Priority: ?

Request caches

Caches here last only for the life time of the request and are only available to the browsing user.

Course categories records

Caches a list of course categories visible to the user.

Since: Moodle 2.5 (MDL-38147)
Component/Area: core, coursecatrecords
Growth: fixes, the number of categories on the site visible to the user will determine this.
Who: everyone

Notes for advanced, multi-server sites

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

Helper caching [tool_uploadcourse]

Since: Moodle 2.6 (MDL-13114)
Component/Area: tool_uploadcourse, helper
Growth: ?
Who: Administrators
Priority: ?

Repositories instances data

Used to cache data on configured repositories to avoid repetitive database calls to load repositories.

Since: Moodle 2.5 (MDL-34346)
Component/Area: core, repositories
Growth: ?
Who: logged in users with one or more accessible repositories.
Priority: ?

Notes for advanced, multi-server sites

• Requires local cache.

More information

• Cache definitions Information on the cache definitions found within Moodle.
• Cache API Details of the Cache API.
• Cache API - Quick reference A short, code focused page of on the Cache API.
• The Moodle Universal Cache (MUC) The original cache specification.