Note: You are currently viewing documentation for Moodle 3.9. Up-to-date documentation for the latest stable version of Moodle may be available here: MUC FAQ.

MUC FAQ: Difference between revisions

From MoodleDocs
(ja link)
 
(12 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Performance}}
{{Performance}}
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.


The Moodle Unified Cache (MUC) on initial inspection  can appear to be a complex
Here is what you need to know (so you can ignore [[Caching| the rest]]).
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 [https://docs.moodle.org/39/en/Caching the rest]).


==What is the MUC?==
==What is the MUC?==


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


==Should I be using the MUC?==
==Should I be using the MUC?==


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


If your site is already running fine then consider '''not changing anything''' as "[https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize premature optimization is the root of all evil]".
If a site is already running fine then consider '''not changing anything''' as "[https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize 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.
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?==
==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.  
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
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.
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?==
==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,
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.
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==
==How do I deploy Memcached==


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


* Install Memcached in a way compatible with your operating system e.g. in Debian/Ubuntu
* Install Memcached and it's PHP support in a way compatible with the operating system e.g. in Debian/Ubuntu
   apt-get install memcached
   apt-get install memcached php5-memcached
* Confiure Memcached, or at least become aware of it's default setup, e.g.
* Confiure Memcached, or at least become aware of it's default setup, e.g.
** 64MB of RAM allocation
** 64MB of RAM allocation
** Runs on port 11211
** 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
* In Moodle go to
**'Site administration > Plugins > Caching > Configuration'
**'Site administration > Plugins > Caching > Configuration'
**Under '''Installed cache stores''' you should see Memcached and an '''Add instance''' action. Click '''Add Instance'''.
**Under '''Installed cache stores''' look for Memcached and click the '''Add instance''' action.
**Give the store a name, i like 'Memcached_MUC'
**Give the store a name, like 'Memcached_MUC'
**In '''server''', assuming the basic config above,  type 'localhost'. '''Save Changes'''.
**In '''server''', assuming the basic config above,  type 'localhost'. '''Save Changes'''.
**Scroll to the bottom of the '''Cache administration''' page you were returned to.
**Scroll to the bottom of the '''Cache administration''' page.
**Under '''Stores used when no mapping is present''' click '''Edit Mappings'''.
**Under '''Stores used when no mapping is present''' click '''Edit Mappings'''.
**In the '''Application''' drop down select your caches name. '''Save Changes'''.
**In the '''Application''' drop down select the caches name. '''Save Changes'''.
* Profit
* Profit


More details can be found in the main [https://docs.moodle.org/39/en/Caching#Memcached Caching documentaion].
See [[Caching]] for more details.


==How much RAM should I allocate to MUC?==
==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.
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?==
==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
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 [https://moopi.uk/course/view.php?id=4#section-5 here].
sessions and one MUC. An example of how to do this can be found [https://moopi.mrverrall.co.uk/course/view.php?id=4#section-5 here].
 
==How can I tell what Cache store I am really using==
[[File:perf.png|thumb|300px]]
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>?==
==I have a cluster of servers, <further question here>?==


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


==What is that little grey triangle?==
==What is that little grey triangle?==
[[File:muc-triangle.png|thumb|300px]]
[[File:muc-triangle.png|thumb|300px]]
This happens when the default Application Cache does not support a requirement
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.  
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
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.
by Memcached.  


Event Invalidation requires '''Data Guarantee'''  which ensures data exists in the
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.
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,
==Where can I find more documentation on setting up the MUC?==
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
See [[Caching]].
whatever else you tell it too).


==Where can I find more documentation on setting up the MUC?==
If you are further interested in the nuts and bolts of the caching system, e.g. cache features (ttl, data guarantee, etc) the [https://github.com/moodle/moodle/blob/master/cache/README.md developers api] is a good place to look.
There is some great documemntaion on this site, the [https://docs.moodle.org/39/en/Caching Caching] page is probably your best place to start.
 
==See also==
 
* [https://moodle.org/mod/forum/discuss.php?d=323628 MUC and localcache] forum discussion


If you are further interested in the nuts and bolts of teh caching system, e.g. cache features (ttl, data guarantee, etc) the [https://github.com/moodle/moodle/blob/master/cache/README.md developers api] is a good place to start.
[[de:MUC FAQ]]
[[es:MUC FAQ]]
[[fr:FAQ sur Moodle Unified Cache]]
[[ja:MUC_FAQ]]

Latest revision as of 15:01, 19 March 2020

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

perf.png

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?

muc-triangle.png

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