Open kabalin opened 9 years ago
Hi Ruslan,
At UW Madison, we run Moodle in a shared clustered environment with one proxy front end load balancer that then passes moodle requests to multiple backend servers depending on load of the specific backend. On that environment we've successfully ran 200 or more students at once. We're currently in the process of developing a test case for 500 students testing through selenium.
The load is also helped to be mitigated by a request splay I make on each successive update. This is done in javascript with the following code. Essentially the setTimeout runs in an infinite loop on the page asking for information from the server, but every student has a re-calculated time between 2-300ms.
var time = 3000 + Math.floor(Math.random() * (100 + 100) - 100);
setTimeout(activequiz.getQuizInfo, time);
Having a custom wait time would create issues with syncing up the client with the instructor's server view, especially when there are timed questions being asked.
As with any Moodle server with a large number of users, you generally do need to have at least a decent amount of resources to even have 100+ students to log in at once. If your server can handle that, then it is likely that it will be able to handle this module.
While UW Madison isn't officially supporting this plugin for the Moodle.org community, I do spend my own personal time on this project, and because of that I can't go too much more in depth of how the UW Madison server system is setup.
I'll just clarify my statement above slightly in regards to the code.
The code is either in the student.js or the instructor.js files, with the function activequiz.getQuizInfo The first function time this function is called is from the quiz_page_loaded function to start the process. Then each successive call, from a setTimeout, has the next time to call recalculated. The base time is every 3 seconds, but the exact time is splayed using a random number between 2-300ms, either added/subtracted so that no 2 clients should be making the server request at the exact same time.
I should also mention that the callback for this loop is as simple and plain as possible to avoid loading in the entirety of Moodle's stack. That specific file is the quizinfo.php file for the plugin.
All other calls, like saving a question, or for the instructor, controlling the question go to a separate callback file.
Hi @jhoopes, thanks for detailed explanation. Yes, we are using loadbalancers and 5 frontends in our setup, it normally copes with a large number of requiests, but in that particular relatimequiz scenario I have explained and fixed in the corresponding issue, it basically made all 100> users querying the status of quiz repetedly every 300ms, which resulted in a huge backend wait list on proxy (it was during peak time, so there were plenty of non-quiz users on site as well that were affected).
Thanks for the time you contribute to the project, looks like an interesting plugin and good to know you build it with performance optimistation in mind. Our learning techs are testing it now, we plan to use it in production environment.
Just wondering, as relatime quiz had serious performance issues due to the high number of AJAX calls, see https://tracker.moodle.org/browse/CONTRIB-5369