Cache definitions

This page contains information on the cache definitions within core.
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

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.