MUC FAQ

The Moodle Unified Cache (MUC) on initial inspection can appear to be a complex off-putting beast and this can lead to it either being ignored or, as is often the case, poorly configured.

Here is what you need to know (so you can ignore the rest).

What is the MUC?

The MUC is a cache, a cache is a store of data which is easier/faster to retrieve than if it came from it's source. It saves (computing) effort and makes Moodle faster.

Should I be using the MUC?

Yes, and sites running Moodle 2.4 or above are already using the MUC.

If a site is already running fine then consider not changing anything as "premature optimization is the root of all evil".

By default MUC uses the file system to store it's cached objects, this already speeds thing up greatly compared to using no MUC at all. By further configuring the MUC we are just trying to make it faster.

What is wrong with the default file-system MUC?

Not much at all, but the MUCs performance is dependant on the read/write speed of its storage medium.

Typically disks are slow but safe (persistent) storage. MUC data does not need to kept safe as it can always be regenerated and so can afford to be kept somewhere fast yet volatile, like RAM.

How can I make MUC faster?

Using a RAM based cache is the best way to make the MUC fast and there a few tools we can use to do this, such as, tmpfs, Memcached, APC, Redis and overtime probably more... A good place to start if unsure of any specific requirements is Memcached as it is common, well tested, fast and easy to deploy.

How do I deploy Memcached

This is by no means exhaustive, and will vary depending on the OS etc. But for simplicities sake...

• Install Memcached and it's PHP support in a way compatible with the operating system e.g. in Debian/Ubuntu

 apt-get install memcached php5-memcached

• Confiure Memcached, or at least become aware of it's default setup, e.g.
  • 64MB of RAM allocation
  • Runs on port 11211
• In Moodle go to
  • 'Site administration > Plugins > Caching > Configuration'
  • Under Installed cache stores look for Memcached and click the Add instance action.
  • Give the store a name, like 'Memcached_MUC'
  • In server, assuming the basic config above, type 'localhost'. Save Changes.
  • Scroll to the bottom of the Cache administration page.
  • Under Stores used when no mapping is present click Edit Mappings.
  • In the Application drop down select the caches name. Save Changes.
• Profit

See Caching for more details.

How much memory should I allocate to MUC?

The default on most Memcached deployments is 64MB and this is probably more than enough for a standard Moodle install. As a real world example, checking a live site with ~6000 individual user logins over the last 24 hours, was Memcached MUC usage was ~11MB (Moodle 2.8 with 26 additional plugins).

Most importantly when implementing an in memory cache such as Memcached is to monitor and understand its use in your own deployment as requirements can vary wildly.

I'm already using Memcached for sessions, can I just reuse that?

Nope, afraid not. If the MUC purges so will sessions, all users will be logged out. Two Memcached instances are required in this scenario, one for sessions and one MUC. An example of how to do this can be found here.

How can I tell what Cache store I am really using

Temporarily switch on performance debugging at,

Site administration Development > Debugging > Performance info.

This adds some useful information to the the footer of all pages (if your theme supports it) including MUC objects and the cachestore they came from .

I have a cluster of servers, <further question here>?

You are probably beyond the target audience of this FAQ in terms of your system administration foo.

What is that little grey triangle?

This appears under Stores used when no mapping is present when the default Application Cache store mapping does not support a requirement of one or more of the cache definitions.

For example, of the default application caches, Event Invalidation is not supported by Memcached. This is because Event Invalidation requires Data Guarantee which ensures data exists in the cache once it is put there. It is never cleaned up to free space or because it has not been recently used. Because Memcached evicts objects from it's cache it cannot be used for Event Invalidation.

This is not a problem as Event Invalidation will simply use the file-system cache, or if specified a compatible secondary application cache, or one allocated directly to the Event Invalidation definition.

Where can I find more documentation on setting up the MUC?

See Caching.

If you are further interested in the nuts and bolts of the caching system, e.g. cache features (ttl, data guarantee, etc) the developers api is a good place to look.

See also

• MUC and localcache forum discussion