Installation help

 
 
Picture of Danny Wahl
MUC is here, now what?
Group DevelopersGroup Particularly helpful Moodlers

I just upgraded to 2.4 this morning and the whole cache administration section is there.  Awesome!  I don't really understand caching: not awesome!

I see that it seems to come down to 6 "basic" options: file cache, memcache, memcached, mongoDB, session cache, static request cache

if you have nothing else you'll have these three: file cache, session cache, static request cache

Those three are pretty straight forward and seem to be either a memory or disk cache (haven't read into it).  What I'd like to know more about is which of the other 3rd party implements are "best" and how to "best" implement them.

our environment is split between two servers:

moodleweb: apache, php, apc, 2nd data volume (for moodledata), 6Gb ram

moodlesql: postgres, 6Gb ram

 

Thanks!

 
Average of ratings: -
Walking on the snow towards Lago Nero...
Re: MUC is here, now what?
Group DevelopersGroup Particularly helpful Moodlers

Hi Danny,
MUC makes usage of three different scopes for caching: request, session, application. By default they are mapped using resources available in all the installations i.e. PHP static, PHP session, files within Moodle dataroot, under $CFG->cachedir.

That being said, if you have enough memory room (at least 128MB, it depends on the number of definitions being mapped) for a memory-based caching service you could install it and map:

a. one/all the default scopes to your caching service, e.g. request into your memcached instance;
b. a particular cache definition, e.g. core/string into your redis instance configured as drop-in replacement for memcached.

What required is:

  1. a supported caching mechanism; please, consider even the so called memcached drop-in replacements;
  2. the PHP support for that mechanism;.
  3. select where to install the supported caching mechanism: it's common practice to install it on the front-end level, strictly closed to localhost.

Besides, starting from 2.2 there is an interesting option, $CFG->cachedir, to let administrators to configure the default caching file store within the context of the front-end, really useful when you deploy Moodle in a load balanced cluster environment; the same for $CFG->tempdir, see config-dist.php for details.
MUC almost requires to configure $CFG->cachedir within a local disk to each front-end, for default best perfomances or - MUC rocks! big grin - to create a new file store instance mapped to a local folder and to map the application type to that local (to the n-th front-end) file store.

HTH,
Matteo

 
Average of ratings:Useful (3)
Walking on the snow towards Lago Nero...
Re: MUC is here, now what?
Group DevelopersGroup Particularly helpful Moodlers

Hi All,
there is a big mistake in a sentence of mine in my above post, about the possibility to move the $CFG->cachedir into a local front-end node or to unshare a cache definition without putting attention of what that definition does and expects about cache invalidation.

Given the final and current design, there's no way to safely unshare that folder/a cache definition - you can still add different but shared MUC stores - and things are going to change for 2.6.

More details in:

HTH,
Matteo

 
Average of ratings:Useful (2)
Tim at Lone Pine Koala Sanctuary
Re: MUC is here, now what?
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

That MUC control panel is a bit like the big mixing desks you see in concert halls. It gives you lots of knobs to twiddle, but unless you know what you are doing, it is going to be difficult to get a good result.

Perhaps it is better to say "Until we, as a community of Moodle administrators, generate some experience it will be difficult to make good recommendations."

So, anyone who can measure their Moodle site while they try different things and report back about the effect is making a useful contribution.

Note that the default configuration for MUC mostly designed to be the equivalent of how Moodle 2.3 worked, so initially the performance characteristics are likely to be the same as you are familiar with. (Hopefully showing a small improvement already.)

The thing that a number of people have done in earlier versions on Moodle (by hacking the code) is to move the session storage out of of the database, and in to memcache. So if you want a good first thing to try, try moving the session caches to a memcache server.

If at all possible, please monitor your servers carefully before and after the change, to see what effect that has.

Can someone who knows about these things suggest a basic set fo things to measure?

 
Average of ratings:Useful (1)
Picture of Howard Miller
Re: MUC is here, now what?
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

As (is often the case) I had no idea what you were all talking about I did some digging. Moodle Universal Cache. Seems a bit light on documentation but I did find this...

http://docs.moodle.org/dev/User:Sam_Hemelryk/MUC_proposal

EDIT:
That sounded a bit rude. I mean *I* never know what's going on, rather than I don't know what you are talking about. Stop digging now tongueout

 
Average of ratings: -
Me at the Moodle Moot NZ11
Re: MUC is here, now what?
Group Particularly helpful Moodlers

Yeah, I have to say that this is a really interesting area.
But agree with Howard that documentation is lacking right now.
This did surprise me a little, as clearly there has been a lot of thought and a lot of work put into this.
Do we have any documentation coming on this area? (I know its just the first stage) but I can imagine this giving boost in performance that many Admins will want to be using it correctly smile

 
Average of ratings: -
Just wondering . . .
Re: MUC is here, now what?
Group Particularly helpful Moodlers

Come on guys, you know everyone hates documentation.

I'd like to see a few standard tests built in that can be used for comparison. A little dashboard, that is easy to get to, measure and report.  Comparisons are difficult otherwise.

-Derek

 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: MUC is here, now what?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

I agree the documentation is a bit lacking. I tried to fill in a bit on http://docs.moodle.org/24/en/Caching#How_to_use_the_caching_settings, although i've not managed that much, and filled MDL-37145 to improve it. I had some ideas on how to improve that screen there too.

Although, I have to say this is a pretty hard thing to document to be understandable to most people, because its a very advanced piece of configuration which probably only relevant to users who already know what mongodb, memcached and redis are... :S

 
Average of ratings:Useful (2)
Mary Cooch
Re: MUC is here, now what?
Group Documentation writersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup TestersGroup Translators

Thanks Dan for this valiant effort - I have no idea what mongodb, memcached and redis are (hence would have no chance to help with documentation) but I will start dropping them into conversation to make myself sound cleverbig grin

 
Average of ratings: -
Picture of Luciano Silva
Re: MUC is here, now what?
 

Voted for caches' doc improvement.

 
Average of ratings: -
Picture of Anna Jonna Ármannsdóttir
Re: MUC is here, now what?
 

Thanks for the documentation. I wanted to also read Tim Hunts article from the 02 may but it seems to be misplaced. I believe the correct link is here: http://tjhunt.blogspot.com/2013/05/performance-testing-moodle.html

 

 
Average of ratings: -