Talk:The Moodle Universal Cache (MUC)

Sam, have you also reviewed all the caching that Moodle already does. For example

• in accesslib.php
• the cache_flags table, and everywhere that is referred to
• in session
• language strings, theme stuff (basically everything cleaned by 'Purge all caches')
• caching filter_text results in the DB.
• does the course.modinfo cache fall into your scheme?

I think you should pay more attention to things that are done in our production code, than hypothetical stuff people have written. That is, the new system should be a super-set of, and a refactoring of, our existing code, not some completely new thing that has been bolted on.

It seems that what you have done so far is just a completely new, bolted on system. Instead, what I would expect to see is:

1. Change all the areas of Moodle that currently do caching to use the new caching back-end library.
2. Results of before and after performance and load tests to prove that the new caching architecture has the same performance characteristics of the old system.
3. Then look for areas to add new caching, and prove that that really is a performance win through more load testing.

Actually, in steps 1. and 2. it would be better to change one area of existing caching at a time.

Doing a proof of concept is all very well, but I really hope that this is the kind of prototype that gets thrown away.--Tim Hunt 16:04, 30 April 2012 (WST)

Push expiry (sam comment)

Just an opinion, but I think a comprehensive caching system should not be heavily based on time-to-live, except for cases where that time is very short (~1m).

Our users generally expect that if something is updated, it updates immediately and not, say, in ten minutes. Moodle users as a whole also exhibit this property.

I think the prime focus of a Moodle cacheing system should be on fixed expiry. For example, let's say that we cache the mdl_config table. This cache could be set up with, say, 30 seconds expiry, which in practice would probably be 'good enough', but there might be cases where this causes confusion if you change mdl_config and then try again immediately. Similar for config_plugins.

A current example of doing this right in Moodle is the role data. If you change somebody's role, this takes effect immediately, even though role membership within a course is normally cached for duration of user session.

And an example in Moodle where it does NOT do this but definitely should is groups; if you change somebody's group, and they don't log out/in again, some parts of the system (that use the cached data in session) won't notice, whereas other parts (that do direct db queries each time) will.

In order to implement this type of system there needs to be a concept of scope for caches (e.g. 'course scope'). Then some way, in a SINGLE query per request, of getting the list of last-changed dates for ALL information at all scopes currently relevant to the user. (Note: I have a feeling it will make sense to just use 'course' and 'system' as available scopes rather than, say, all contexts.)

For example there could be 'roles/capabilities last change' date per course. Any time any teacher changes a role or override this number changes and users on that course will all refresh their cached data about that. (As I understand it this is actually what happens already, just saying it should be generalised.) Same for groups and other things. This obviously only works where changes to data are relatively rare compared to access of that data.

sam, and Sam, there is already a concept of a 'roles/capabilities last change'. that is exactly what the cache_flags table does. If you have never gone into the depths of accesslib.php and tried to fix bugs there, then you probably are not ready to try to introduce caching to Moodle. (cache_flags was added by Martin Langhoff as part of the big roles performance boost in Moodle 1.8, or was it 1.9).--Tim Hunt 18:02, 30 April 2012 (WST)

Tim, did you read my comment above where I said that it already exists? :) The cache_flags table needs to be replaced or subsumed by this new system, is my point, and all new caches should use that system rather than expiry time where possible because it's frankly better. Sam marshall 18:19, 30 April 2012 (WST)

More comments from Tim

Cache types -> Request cache

I think it is misleading to say "It is also important to point out that this cache is of course user specific". Think, for example, about the cron script.

I cannot see any case in which it would make sense for the Request cache to be anything other than an in-memory cache.

The cron use-case shows that it does need to be possible to expire things from the memory cache.

Cache types -> Session cache

It just occurs to me, when you say "the idea behind it is to separate out information that would be blowing out the current session size and allow an installation to specify an instance dedicated to its storage.", that is a good point. We can get the best of both worlds by keeping the PHP session small, and then linking to more data in another form of storage.

Cache types -> Application

This is really the key area, and it is probably oversimplifying to refer to this as a single cache. Really, Moodle will require lots of different caches for lots of different things. So, separating out the session cache from the application cache is really like saying that Moodle only has three different types of file area, draft files, user profile images, and all the rest.

Actually, file areas might be an interesting analogy for cache types. Or perhaps not.

Cache plugins

should be called Cache back-end plugins, to make it clear.

Configuration

Here, you only talk about code issues. I have just spend a few minutes trying to think about what the admin screens for this should look like? It turned out to be a good question to ask oneself. How do you think it should look? What control should we give admins? Here is a crazy idea:

 Context cache:
   Level 1:
     Cache up to:     100 entries
     In:              memory
   Level 2:
     Cache up to:     1000 entries
     In:              memcache
     Memcache server: localhost
   (Add another level)

 Crazy idea cache
   Level 1
     ...

--Tim Hunt 22:08, 19 July 2012 (WST)