Mitigating Student Avalanches at the Start of a Quiz
In a quiz with strict time constraints students tend to refresh the page too often, just to make sure if the attempt is available yet.
This unnecessarily increases the server load, and is a problem with large number of students.
Synchronized start of many attempts places a heavy short-time load in the Quiz core engine. By phasing in access, the impact is minimized.
Some quiz configurations generate particularly high server loads.
Some quiz schedules generate problems for the students.
By having the students enter gradually the load curve is flattened and the system can handle many more users doing tests.
The “Delayed Attempt” plugin makes the “Attempt quiz now” button auto-enable at quiz open timing plus a randomized delay, without requiring to refresh the page.
This is done by a client side countdown timer (javascript) which is initiated when the page is rendered in the browser. The page, displays the time remaining to start the quiz using an animated countdown.
The plugin is implemented as an access-rule plugin overriding the default activity page render.
A pseudo-random delay is assigned to each student depending on the number of students and a set of site-wide parameters as fixed rate of entry, maximum allowable delay.
An optional message for the students can be defined for all quizzes in the platform.
An optional check and advice message for teachers can be defined for all quizzes in the platform.
With all these limitations, the final entry rate is the one needed to meet all specifications. In this example it would be 200 students/1.5 minutes = 133 students/minute (about 2 per second). If we want to spit out the input rate we will have to give up the absolute limit or the percentage of the completion time. In the UVa we have decided that a long delay is not functionally admissible in the case of short exams, because it would make some students almost finish and others would still be starting.
Mobirise website maker - More info