When realtime quiz is run with the high number of client (100+), it causes two issues:

1. Before the first question has been activated and displayed to client, 'getquestion' AJAX request is being sent by client every 2 sec, this means that all 100+ will be hitting server repeatedly every 2 seconds (not all at the same time, this depends on when people press "join quiz" button which is random). Modern systems can handle that with no issues, however making the check interval higher (e.g. 5 sec) on slower or heavily loaded systems may increase performance.
2. The more serious problem arises when the client answered the first question. Once the answer is submitted, the client is waiting for the question timeout before sending 'getresults' request. Given that all clients received the first question at different times (caused by initial 2 seconds interval difference and server response time), the question timeout is not "synced" between clients, some may expect results to come a little earlier than question reached timeout on teacher's browser, in which case client will receive 'waitforresults' response with more precise timeout, after this timeout client will try to gain results again, and if calculated timeout is 0, but results are not ready yet, client will get another 'waitforresults' response with timeout 0.1 sec. This is causing another two things:
   1. Some clients start "stress-testing" server with 'getresults' requests with 0.1 sec interval, this is inevitable if you have say 100 clients, many will reach this 0.1 sec timeout scenario - fortunately this will not last long.
   2. Clients will get "synchronised" after receiving a first question result because of scenario described above. The new 'getquestion' requests all clients will be sending more or less simultaneously (again, not good performance-wise).

All above can be easily replicated with a few clients and apache log monitoring. In the large scale, basically we hit moodle response time problems if someone is running realtimequiz within a big lecture theatre, the number of queued requests becoming enormous which causes slowness.

The patch that solves this is developed and will be published here later today.