Cache definitions

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

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 utilized 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 a 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. instructors, 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 optimize 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 utilized within get_fast_modinot() a function that is called often in LMS when querying or displaying information on a course, section or activity.
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 access 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.

Component/Area: core, calendar_subscriptions

Growth: determined by the number of calendar subscription 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.

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 LMS, regardless of the user’s state or what is being done.
You should map this cache to the fastest backend you’ve got available.

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 to get-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 determined on how you have configured LMS and what is set to be displayed.

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.

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

Component/Area: core, database meta

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

This is not often used within LMS and when it is used occurs when editing happens and multiple caches need to purge, 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.

Component/Area: core, eventinvalidation

Growth: fixed, events are subscribed to by definition and will only change during the 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 the list of event observers.

It is updated on install/update while initializing a list of event observers.
This cache is accessed when an event is trigged.

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.

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

Component/Area: availability_grade, items

Growth: ?

Who:?

Priority:?

HTML Purifier – cleaned content

This is a cache of texts (forum posts, resources, intros etc) from all parts of LMS 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 safely stored in local caches on cluster nodes.

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

• This expects a shared cache
• If not shared, must be manually purged after every upgrade or change of $CFG->allowobjectembed setting
• 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 LMS, it caches each and every language file used within LMS.
It’s 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 LMS.
This is a prime cache to configure, map it to the fastest backend you’ve got available.

The string cache uses the hash of the revision, language, and component of a language file as the key and the array found within the corresponding file is the data.
Static acceleration is used on this cache to speed up the 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 instructor + users. Admins and managers being able to complete more actions and often across different components and plugins often require that many more language files be accessed for a page than a user such as an instructor or user requirements.
When testing your cache configuration ensure you test as a user.

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

Priority: 5

Notes for advanced, multi-server sites

• If shared between sites please be aware that any language customizations will also be shared.
• 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 the upgrade, installation or uninstallation of languages.
• 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 LMS on any site with more than one language installed.
As its a small, fixed size cache on a site with multiple languages installed it a good idea to map this to the fastest backend you’ve got available.

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 LMS, they are in most situations considered public information (like course names) and can be seen by all users.
The process of listing these course contacts can be expensive, however, the course contacts are shown only on select pages.

Component/Area: core, course contact

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 LMS 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 the site through the admin interfaces.
Primarily people accessing this page benefit from the existence of this cache.

Note: This must be a shared cache.

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 the 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 the portfolio is enabled.
• Requires shared cache.

Question definitions

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

Component/Area: core, questiondata

Growth: ?

Who:?

Priority:?

Notes for advanced, multi-server sites

• This gets updated when the 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).

Component/Area: availability, scores

Growth:?

Who:?

Priority:?

YUI Module definitions

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

Component/Area: core, yuimodules

Growth: fixes, the number of LMS YUI modules within core and plugins. This will only change during the upgrade or installation/removal of plugins.

Who: everyone, this is used whenever LMS YUI modules are used on a page and that is most pages.

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 the current user. Helps to browse the list of categories.
This is also used during course category management.

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 LMS

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 the limited lifetime.

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]

Component/Area: repository_skydrive, foldername

Growth:?

Who:?

Priority:?

Request caches

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

Course categories records

Caches a list of course categories visible to the user.

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 the changesincoursecat event is triggered.
• Require local cache.

Helper caching [tool_uploadcourse]

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.

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.