Previously, quiz statistics processing happened on a scheduled task.
This task looked for all quizzes with completed attempts, then
determined if those quizzes had a statistics calculation that's newer
than the most recent attempt, then ran the statistics calculation if
needed. It was hard coded to stop processing after 1 hour.
The queries involved in determining which quizzes needed processing
weren't terribly efficient, and combined with the 1 hour limit this made
the statistics unusable on large sites, where they are the most useful.
This converts the scheduled task to an ad-hoc task, and uses an event
observer for mod_quiz\event\attempt_submitted to queue a task when
it is needed. This removes the need for a query to work out what needs
processing, and allows the task processing to be scaled up as needed.
This new parameter / property will decide if we want to reduce
the run data before processing it:
- By default it will be disabled in table mode.
- By default it will be enabled in graph mode.
- The defaults can be changed by adding reducedata=[0|1] in the URLs
- Once data reduction is enabled, it stays enabled while
navigating within the xhprof reports.
This covers the 2 new functions with unit tests:
- xhprof_topo_sort()
- reduce_run_data()
Note that the example graph used in the provider is the
one shown in the issue to explain the reduction procedure.
Here we are reducing the xhprof runs data by removing the
__Mustache==>__Mustache calls and all the orphaned data.
To save N iterations what we are doing is:
0. The information is "topologically" sorted, so we ensure that
all the parents in the data are processed before the children.
(this will help a lot when cleaning orphaned data, see below).
1. First pass, all the candidate (by regexp) calls are removed
from the run data.
2. Second pass, all the orphaned information (calls that have
ended losing his parent) are also removed, so data is consistent.
Note that, normally we would need N passes to remove all the
orphaned data (because each pass creates new orphan candidates),
but, as far as we have ensured that the information is topologically
sorted (see point 0 above), all this can be done in one unique pass.
TODO:
- Add unit tests.
- Enable some system to be able to decide which utilities we
want to get the data reduced and which ones will continue
using the complete data. Right now the reduction is being
applied to all the utilities (both table and graph views).
- Document the change and, if implemented, the way to select
between complete/reduced data.
- Consider adding some caching to speed-up the reduction process
(some TODOs have been left in the code pointing to the critical
points).
* Use a unique ID the date nodes in the HTML tree to be able to find the current node.
* Look for nodes in the same tree "leaf" and work on conflicts in this single leaf/branch.
* Use the appropriate gradebook plugin string for the page title.
* Improve gradebook page titles set by grade_get_plugin_info() by
listing the unique identifying information for the page first
(e.g. the gradebook plugin name), followed by broader information
(Grades + Course name), separating these bits of information using the
pipe `|` character.
For more information, check out
https://www.w3.org/WAI/WCAG21/Techniques/general/G88
If a quiz had a long job to calculate statstics running, this would
cause pages that may also attempt a recalculation (the statistics report
page or question bank) to load very slowly, and possibly result in a
database deadlock.
This change will firstly prevent the question bank page performing
analysis calculations at all, since these are not required for this
page, which will speed up loading and prevent deadlocks on this page.
Secondly, this adds a lock to the recalcuation process so that it cannot
run twice concurrently. This will present the user with a message to
indicate that it is waiting for a running calculation until it is
complete, and eventually it will timeout with a message and debugging.
