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
- Since
- Component/Area
- core, calendar_subscriptions
- Growth
- Who
- Priority
Concept linking [mod_glossary]
- Since
- Component/Area
- mod_glossary, concepts
- Growth
- Who
- Priority
Config settings
- Since
- Component/Area
- core, config
- Growth
- Who
- Priority
Course categories tree
- Since
- Component/Area
- core, coursecattree
- Growth
- Who
- Priority
Course group information
- Since
- Component/Area
- core, groupdata
- Growth
- Who
- Priority
Database meta information
- Since
- Component/Area
- core, databasemeta
- Growth
- Who
- Priority
Event invalidation
- Since
- Component/Area
- core, eventinvalidation
- Growth
- Who
- Priority
Event observers
- Since
- Component/Area
- core, observers
- Growth
- Who
- Priority
External badges for particular user
- Since
- Component/Area
- core, externalbadges
- Growth
- Who
- Priority
Grade items cached for evaluating conditional availability [availability_grade, items]
- Since
- Component/Area
- availability_grade, items
- Growth
- Who
- Priority
HTML Purifier - cleaned content
- Since
- Component/Area
- core, htmlpurifier
- Growth
- Who
- Priority
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
- 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
- Since
- Component/Area
- core, langmenu
- Growth
- Who
- Priority
List of course contacts
- Since
- Component/Area
- core, coursecontacts
- Growth
- Who
- Priority
Plugin info manager
- Since
- Component/Area
- core, plugin_manager
- Growth
- Who
- Priority
Question definitions
- Since
- Component/Area
- core, questiondata
- Growth
- Who
- Priority
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]
- Since
- Component/Area
- availability, scores
- Growth
- Who
- Priority
YUI Module definitions
- Since
- Component/Area
- core, yuimodules
- Growth
- Who
- Priority
Session caches
Data cached here belongs to the user browsing the site.
Course categories lists for particular user
- Since
- Component/Area
- core, coursecat
- Growth
- Who
- Priority
Data used to persist user selections throughout Moodle
- Since
- Component/Area
- core, userselections
- Growth
- Who
- Priority
Folder name cache [repository_skydrive]
- Since
- 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
- Since
- Component/Area
- core, coursecatrecords
- Growth
- Who
- Priority
Helper caching [tool_uploadcourse]
- Since
- Component/Area
- tool_uploadcourse, helper
- Growth
- Who
- Priority
Repositories instances data
- Since
- Component/Area
- core, repositories
- Growth
- Who
- Priority
