Performance improvements for large courses #164
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 @ndunand,
We use this plugin on a few very large courses (> 150k enrolments) and have about ~50k responses per group.
As a result, most module result pages take a long time to load, if ever. I've adjusted the module for our use case, to work around loading all user / group records into the memory before performing some operations on them in favour of SQL counts and moodle recordsets.
Feel free to let me know what you think. This is the current version we are using and have reduced the load time after 10k enrolments.
One thing to note is that with the introduction of pagination for the
report.php
view, theshowunanswered
option no longer works as expected, as I opted not to introduce an anti-join, or load all user enrolments into memory. For us, this is not a feature we use, though if you have any suggestions I would be more than happy to work with you to re-introduce this.Improvements introduced:
report
view. If a download action has been sent, we do not enforce a limit and proceed as usual.get_records_sql
calls with record-set iterators, where required.