Caching stores frequently access data in a temporary storage and expedite its access using a cached copy as opposed to refetched (from disk) or recomputed (in memory) data. This has proven to be one of the most efficient performance optimization techniques and Moodle is no exception.
Moodle contains a powerful caching framework called Moodle Universal Cache (MUC), which allows certain functions to take advantage of different configured caching services (https://docs.moodle.org/en/Caching). A typical example of a function that makes use of caching is string fetching, especially when multiple languages are supported.
Before we take a look at how MUC works, let's explore some basic concepts first, namely cache types (modes), cache stores, and cache definitions.
There are three different cache types in Moodle, often referred to as cache modes:
- Application cache: The application cache deals with operations that are Moodle-specific, for example, caching of language strings or configuration settings. This is the most commonly used cache as it has the highest impact on Moodle performance.
- Session cache: This is basically the same as your PHP session cache. It is only used in very few scenarios, and we do not need to cover this in further detail.
- Request cache: As the name Moodle:request cache suggests, this type of caching is only stored for the lifetime of a request and allows developers to optimize code. Again, this is not a cache type that we, as administrators, have to worry about.
Here's an overview of the different cache types:
|
Feature |
Application |
Session |
Request |
|---|---|---|---|
|
Lifetime |
Persistent |
Session |
Request |
|
Applicable to |
All users |
User |
User |
|
Performance impact |
High |
Medium |
Low |
|
Default cache store |
Filesystem |
PHP session |
Memory |
Simply speaking, a cache store is a plugin that connects Moodle to a physical storage where the cached data gets stored; this is also referred to as cache backend. The default cache stores are in the form of a filesystem (for a cache store application), PHP session (session), and memory (request). For most setups, these are sufficient, but for larger sites, it is beneficial to make use of a dedicated application cache store.
Moodle ships with three application cache store plugins, namely Memcache, Memcached, and MongoDB. Other plugins, such as APC, WinCache, and XCache, can be found in the Cache Stores section of https://moodle.org/plugins/. All the supported cache stores can be found by going to Plugins | Caching | Configuration. On our system, only Memcached has been installed and configured at the system level, hence the tick in the Ready column. The Supports column indicates which features are supported by the cache store; the options are ttl (time-to-live), data guarantee, key awareness, and searching by key.
For each configured cache type, you have the ability to add instances via the respective link in the Actions column. Each cache store has different settings, which depend on the supported features in the cache backend. Here are the parameters available in the Memcached store:
Once you have set up your cache store and your cache instance, respectively, you will need to add so-called store mappings. This is done as part of the cache definitions, which we will cover next.
Different features in Moodle support caching. In earlier versions, we had a single monolithic cache that was either harnessed by a feature or it wasn't. Now, via the MUC, each feature is represented via so-called cache definitions, which can be configured individually. At the time of writing this, there are over 30 cache definitions available. It is expected that this number will increase with each version. For each definition, the following information is available:
|
Name |
Description |
|---|---|
|
Definition |
Name of feature that is being cached |
|
Mode |
Application, Session, or Request. |
|
Component |
The Moodle component that the definition belongs to (core or module) |
|
Area |
The section that the feature belongs to. This is only relevant to developers. |
|
Store mappings |
If no customization has taken place, this will be the default cache store of the given cache mode, otherwise, the newly set value (refer to the following point). |
|
Sharing |
By default, this will be Site identifier. When modified, the possible values can be Everyone, Version, and Custom key (refer to the details further in the later sections). |
In the Actions column, you have the option to Edit mappings, Edit sharing, and Purge the cache for this specific definition.
Editing mappings lets you specify which cache store is being used as the primary store and, for some definitions, as the final store. This is where you specify which store is being used for a particular feature (cache definition).
By default, each cache definition is shared across the instance of the site. However, there are scenarios where you might want to change this to any of the following options:
|
Sharing option |
Description |
|---|---|
|
Everyone |
Every user in the system. |
|
Site with the same ID |
If you run a single version of Moodle on a single server, this is identical to the preceding point. If you run Moodle on a multiserver setup, all systems will be included. |
|
Sites running the same version |
If you run multiple Moodle instances from one |
|
Custom key |
If you run multiple Moodle instances from one |
In order to clear a cache of a definition, simply select the Purge option.
The following diagram visualizes the mapping of cache definitions and also shows the concepts that were previously covered:
There are two more elements that you can see when you navigate to Plugins | Caching | Configuration, which we haven't covered yet:
- Summary of cache lock instances: There are different locking mechanisms in shared environments, caches being no exception. By default, Moodle ships with a default file locking mechanism. It is possible to install additional lock instances. However, at the time of print, no such plugins are present at the https://moodle.org/plugins/.
- Stores used when no mapping is present: Here, you can specify which default mappings will be used for which cache type.
Now that we have covered all the relevant concepts of MUC, let's have a look at the things to be considered when optimizing your Moodle site.
We have already explored the complexity of the MUC. While this provides us with enormous flexibility in terms of granular optimization, it makes it impossible to come up with a one-size-fits-all configuration. Somebody in the Moodle community once compared the MUC control panel with a big mixing desk at a concert: it gives you a lot of knobs to play with, but unless you know what each of them does and how they work together, you are unlikely to get good results.
There are a number of factors that impact the configuration of the MUC:
- Usage of the system (volume, diversity, functions, and type)
- Underlying infrastructure (single server, multiple server, virtualization, and so on)
- Types of cache stores used
In particular, when talking about the usage of the system, it is almost impossible to quantify this since it's changing constantly. During the summer break, there will be very little usage; during exam time, the load on the system is likely to rising, and so on.
Performance optimization is an ongoing exercise, which is accompanied by regular performance testing. Moodle provides us with a basic performance test for different cache types (Plugins | Caches | Test performance). Here is an example where you can see the results of 10,000 unique requests: the file cache is significantly slower that the sessions cache, a behavior that is not unexpected:
While it is nice to have a built-in performance test tool in Moodle, it has two major shortcomings: first, some plugins are Untestable, for instance, Memcache and Memcached. Second, the test runs only mimics some unique requests but does not mirror their behavior if there are users on your system. To overcome these drawbacks, proper profiling and monitoring is required. This will be dealt with briefly at the end of this chapter.
There are a number of caching-related settings:
- Language caching: We dealt with localization in great detail in Chapter 9, Moodle Configuration, where we covered the configuration of Moodle. In addition to keeping the number of languages to a minimum, language caching should be utilized.
Language packs are cached to speed up the retrieval of language strings. You find the Cache language menu and Cache all language strings parameters by going to Languages | Language settings. Unless you are modifying a language pack, it is highly recommended that you leave this setting as Yes. It caches all the language strings rather than loading them dynamically.
- Theme caching: Moodle caches the images and style sheets of themes either locally in a web browser or on a server. Unless you are designing or modifying a theme, the Theme designer mode, which you see when you go to Appearance | Themes | Theme settings, should remain off.
You can clear the theme cache using the Clear theme caches button by going to Appearance | Themes | Theme selector.
- Javascript Caching: Moodle makes use of Javascript and AJAX. The Cache Javascript setting that you see when you go to Appearance | AJAX and Javascript should be kept on unless you are a developer.
- RSS caching: RSS feeds are cached locally. You can modify the time after which the cache is refreshed by changing the Timeout parameter by going to Plugins | Blocks | RSS clients.
- Networking caching: Moodle uses cURL to fetch data from remote sites. The cURL cache TTL setting can be modified by going to Server | Performance. The larger the time-to-live value is kept in the cache, the better the performance. More on networking in Chapter 15, Moodle Integration.
- Repository caching: When browsing external repositories, such as Google Docs or system files, the file listing is kept in a local cache. The amount of time that the listing is kept for can be changed via the Cache expire parameter by going to Plugins | Repositories | Common repository settings.
You can purge all these caches in a single operation by pressing the Purge all caches button when you navigate to Development | Purge all caches. Effectively, this clears out all the directories in $CFG->dataroot/cache. While this feature is more relevant to developers, it is a recommended step after installing updates or when your system is behaving oddly.
