Details
-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
3.5, 3.5.1
-
MySQL
-
MOODLE_35_STABLE
-
MDL-63285-master
-
3
-
Internationals - 3.8 Sprint 4, Internationals - 3.8 Sprint 5, Internationals - 3.8 Sprint 6, International 3.9 - Sprint 3
Description
One of our plugins (block_semester_sortierung) started experiencing very slow loading times after the events API was rewritten. After doing some optimizations in the plugin, it was found that the bottleneck of the event fetching lies in the
{{\core_calendar\local\event\strategies\raw_event_retrieval_strategy::get_raw_events_legacy_implementation(...) }}
function, more specifically, in the sql subquery which is used to fetch unique events with minimum priority. The problem seems to be that the subquery performs a search in all of the user(s) courses, regardless whether a list of course ids was already supplied as a parameter to get_raw_events_legacy_implementation(..). With users that have a lot of courses (e.g. professors at universities) with a lot of events, this results in very slow fetching of events even for a single course (because the subquery matches against all of the user courses).
The bug is hard to reproduce, because it requires a user who is enroled in many courses, and the courses need to have events in them. Here is the that triggers the bug:
$vault = \core_calendar\local\event\container::get_event_vault();
|
$vault->get_events(
|
null, // time start from |
null, // time start to |
time() - 6 * 31 * 24 * 60 * 60, // time sort from = 6 months ago |
0, // time sort to = 0 |
null, // timestartafterfevent |
null, // timesortafterevent |
200, //event limit |
CALENDAR_EVENT_TYPE_ACTION, // event type |
[$USER->id], // array of users |
null, // array of group ids |
$courseids, // array of course ids |
null, // array of category ids |
true, // with duration |
true, // ignore hidden |
function ($event) { // filter |
return $event instanceof |
\core_calendar\local\event\entities\action_event_interface;
|
}
|
);
|
I have given as affected versions 3.5 and 3.5.1, because the function{{ get_raw_events_legacy_implementation(..)}} was reworked quite a bit between 3.4 and 3.5; however, it still didn't fix the slow loading issue.
Here is a patch that fixes this problem:
All it does is when an array of courseids is provided as a parameter, the same list is used for the subquery too, and not the whole user course list.
Related issues:
https://tracker.moodle.org/browse/MDL-60402
https://tracker.moodle.org/browse/MDL-59438