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, the showunanswered 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:
Simple pagination for the report view. If a download action has been sent, we do not enforce a limit and proceed as usual.
Refactoring logic around counting in favour of SQL counts
Replace large get_records_sql calls with record-set iterators, where required.
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.phpview, theshowunansweredoption 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:
reportview. If a download action has been sent, we do not enforce a limit and proceed as usual.get_records_sqlcalls with record-set iterators, where required.