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 if you are using Moodle 2.4 or above you are already using the MUC.

If your 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 than if there was 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 it's storage medium.

Typically disks are slow but safe (persistent) storage. MUC data does not need to kept safe as it can always be regenerated so it 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 for this, such as, tmpfs, Memcached, APC, Redis and overtime probably more... A good place to start if you are 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 your OS etc. But for simplicities sake...

• Install Memcached in a way compatible with your operating system e.g. in Debian/Ubuntu

 apt-get install memcached

• Confiure Memcached, or at least become aware of it's default setup, e.g.
  • 64MB of RAM allocation
  • Runs on port 11211
• Make sure your PHP has the required support, e.g. in Debian/Ubuntu

 apt-get install php5-memcached

• In Moodle go to
  • 'Site administration > Plugins > Caching > Configuration'
  • Under Installed cache stores you should see Memcached and an Add instance action. Click Add Instance.
  • Give the store a name, i like 'Memcached_MUC'
  • In server, assuming the basic config above, type 'localhost'. Save Changes.
  • Scroll to the bottom of the Cache administration page you were returned to.
  • Under Stores used when no mapping is present click Edit Mappings.
  • In the Application drop down select your caches name. Save Changes.
• Profit

More details can be found in the main Caching documentaion.

How much memory should I allocate to MUC?

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

Most importantly if you decide to implement an in memory cache like Memcached then monitor and understand its use in your deployment as this 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 your users will be logged out. That does not stop you using two memcached instances, 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

If you temporarily switch on performance debugging at Site administration Development > Debugging > Performance info some useful information is displayed teh the footer of all your moodle pages. This includes information about the MUC cache objects set and retrieved as well as the cachestore they came from.

Sometimes, even if you think you have set it up perfectly Moodle will silently fail over to using the default cache stores if it encounters a problem

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 happens when the default Application Cache does not support a requirement of one or more of the cache definitions. Do not panic, it is not important.

For example, of the default application caches only Event Invalidation is not supported by Memcached.

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 (as discussed above/below?) Memcached evicts objects form it's cache it cannot be used Event Invalidation.

The Event Invalidation cache is used to ENSURE events are handled correctly, i.e. the objects exist when they are created and don't exist only when they are purged, this may not occur if the cache object vanishes unexpectedly as may be the case with Memcached.

So Event Invalidation will just carry on using the file-system cache (or whatever else you tell it too).

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

There is some great documemntaion on this site, the Caching page is probably your best place to start.

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.