Cache definitions

From MoodleDocs
Revision as of 01:25, 9 June 2014 by Sam Hemelryk (talk | contribs) (Created page with "This page contains information on the cache definitions within core.<br /> Each cache definition found within core will be under its own heading and will include a description...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.