Scheduled task related performance related improvement and minor changes #155
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi Catalyst team,
We recent made some changes to the plugin with the main aim to improve the performance of the scheduled task.
The performance issue
The performance issue was raised from a Moodle site that we maintain, which have about 30 mod_reengagement activities in different courses, many of which are legacy courses that have been hidden, or moved to hidden course categories. Each run of the scheduled task now takes over 15 minutes to run, and the logic to mark completion and send emails are only reached after the logic to create in-progress records, at the end of the scheduled task. On some courses, mod_reengagement activities are used to allow users to access subsequent activities following a delay after another activity is completed, and the duration is set to be relatively short period, e.g. 30 minutes or 1 hour. Long scheduled task running time effectively adds a lot of extra time to the configured duration, resulting in confusion to users.
The solution
We have made two changes to improve this:
nextruntime
of the expected completion time / email time, so will be triggered by the Moodle cronjob separate from the scheduled task.Bug fix in completion time / email time display
This is related to issue #151. When a student access the plugin view.php page, the completion time / email time displayed is fetched by finding a random in progress record of the user, without limiting the in-progress record to the current mod_reengagement activity only. The pull request contains the fix to this issue.
Other changes
The PR also contains a small change to add an option to reset data belonging to the mod_reengagement plugin when the course is reset. I noticed that the reset function was actually implemented, but the option didn't exist, so the function would never be triggered.
Please review the changes, and let me know if you have any questions.
Regards,
Lai