To test this for real you would need a system with multiple servers, using a local cache on each server and a shared cache across all servers. This would then enable you to replicate the problem where when there are multiple requests, some of them have infeasibly long delays because they wait for multiple other users to rebuild the cache. However, if we only need to test that it works to get the data from shared cache when there is older data in the local cache (which is the fundamental change here) then we can simulate this within a single test server if we use a 'local cache' that is a filesystem cache, and manually change the directory to simulate being on another server. First, so as to make testing easier, hack a library function so that building a course cache always takes at least 20 seconds. (Use a test course that builds quickly so that the time is pretty much just 20 seconds.) Open lib/modinfolib.php and insert the line sleep(20); immediately after this line (currently line 700): protected static function inner_build_course_cache($course, \core\lock\lock $lock) { Select a suitable location on your web server computer to store this cache, for example it could be /tmp - anywhere that your web server can access. If you are using Windows, it must be stored somewhere on the default disk drive i.e. drive C. In that location, create two folders 'localmodinfo1' and 'localmodinfo2' Go to the cache configuration screen (admin menu / Plugins / Caching / Configuration). Click 'Add instance' in the 'File cache' line of the top table. Give it the store name 'LOCAL modinfo'. Set the cache path to the full path 'localmodinfo1' folder that you created earlier. If you are using Windows, you can't type colons into this path, and you should probably also not use backslashes, so instead of c:\temp\localmodinfo1, type /temp/localmodinfo1. Save changes. Under 'Known cache definitions', find the line for coursemodinfo (usually first line). Click 'Edit mappings'. Set it so that 'LOCAL modinfo' is the first entry, and a suitable shared cache (e.g. the default one) is the final store entry. Keep this screen open in a tab because you're going to need it again soon. In another tab, view any course page. (There may or may not be a 20-second delay at this point; it doesn't matter.) Back in the first tab, find 'LOCAL modinfo' in the 'Configured store instances' table and click the 'Edit store' button. Change the end of the path from 'localmodinfo1' to 'localmodinfo2' and save changes. Reload the course page. EXPECTED: It should not take 20 seconds. This guarantees that both the 1 and 2 local caches, and the shared cache, all now contain the current version of the course cache. Now edit settings for the course, and save changes. (You don't actually have to change anything.) EXPECTED: There should be a 2x 20 second delays at this point. (This is because editing settings rebuilds the course cache twice, which seems silly, but that's an unrelated issue.) Now the new version of the course will be in the shared cache, and the 2 local cache, but not in the 1 local cache which should still have the previous version. In the first tab, edit the store again and change the path back to 'localmodinfo1' and save changes. Reload the course page. EXPECTED: It should not take 20 seconds. This test proves that the course cache rebuild now only happens once in the local+shared setup, even if an older version is stored on local cache. If you want you can also turn on performance information and watch the cache hits/misses/sets values for modinfo (this is a bit advanced - it is hard to read, and you have to bear in mind that it always loads the site course as well as the one being looked at): After the edit, when the course page first loads (so that it actually rebuilds course cache) there is 1 set on the local cache and 1 set on the shared cache. If you load the course page again at that point, you'll see it has all hits on local and no reference to the shared cache. After you change the cache setting to the other directory (so that it needs to get the newer one from shared cache) you'll see the shared cache appears again, but only with a hit; the local cache now has a set as it's updating the value. Reloading it goes back to having only hits on local cache.