-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 3.3.4, 3.4.1
-
Component/s: Caching, Course, Performance
-
Labels:
-
Testing Instructions:
-
Affected Branches:MOODLE_33_STABLE, MOODLE_34_STABLE
-
Fixed Branches:MOODLE_33_STABLE, MOODLE_34_STABLE
-
Pull from Repository:
-
Pull Master Branch:
MDL-61305-master -
Pull Master Diff URL:
In a large course, rebuilding the modinfo cache (for example when caches are purged, or when you edit a setting on the course) can take a significant amount of time, for example 5 seconds.
With a busy system it is possible that multiple users may access the course within that period. Currently, all of them will result in a cache rebuild. This process is expensive for the database and could cause noticeable delays for users if staff are editing a busy course while students are using it.
Assuming the database has unlimited capacity, here is what the current situation looks like, with R being when a user makes a request, and D when it's done:
User 1 R...............D (5s) - rebuilds cache
User 2 ...R...............D (5s) - rebuilds cache
User 3 ......R...............D (5s) - rebuilds cache
Here is the ideal situation:
User 1 R...............D (5s) - rebuilds cache
User 2 ...R............D (4s) - waits for rebuild
User 3 ......R.........D (3s) - waits for rebuild
As you can see this would result in better performance for users in these cases. It also means the database has 1/3 the work to do, which may be important if you are unlucky enough to have a database without unlimited capacity. (We think this might possibly contribute to one of the situations when our system gets a hiccup.)
It should be possible to implement this behaviour using the Moodle locking mechanism.
