-
Improvement
-
Resolution: Fixed
-
Minor
-
4.1.6, 4.2.3, 4.3
I have been doing some performance analysis on a large site, and found that requests which show/hide a section containing a large number of course modules can be very slow. Analysis of long session locks on the site showed that 10% of locks lasting more than 10s were performing these actions. A big part of the reason for this is that it course_update_section() does the following:
- Set the section visibility
- purge the section from the coursemodinfo cache
- Perform a partial rebuild the coursemodinfo cache for the course
- For each course module,
- call set_coursemodule_visible, which will purge the cm from the coursemodinfo cache, then perform a partial rebuild
- If the section is being hidden, store the visibility in visibleold and purge the cm from the cache again
- Perform a partial rebuild the coursemodinfo cache for the course
This results in 2n+3 writes to the coursemodinfo cache when showing a section, and 3n+3 when hiding a section, including n+2 partial rebuilds, where n is the number of course modules within a section. Each of these writes requires a cache lock.
I propose adding an additional parameter to set_coursemodule_visible() to skip purging and rebuilding the cache, and instead let the calling code be responsible for updating the cache. In addition, a new course_modinfo::purge_course_module_cache_many() function which takes a list of cmids would allow us to purge several course modules from the cache at once, rather than doing it in a loop.
The combination of these would reduce the cache writes to 4 including 2 partial rebuilds, for any number of course modules.
This could also be used in stateactions::set_cm_visibility(), and anywhere else that bulk updates cm visibility.
- blocks
-
-
- Open
-
