Wow!
By the way, this is just a thought and I don't know how it really would work, but seeing these results put it into my mind: would it be possible to simply limit the number of requests the webserver handles concurrently, as another way to solve this problem? That way students will experience varying delays as the webserver waits until a slot is available, instead of having to actually type a password in.
This could appear more like a system problem as it may result in slow responses. But it seems to me you're basically doing the same thing, only manually, by forcing them to type a password. Getting the server to do it would also reduce the delays to the amount actually required in order to ensure consistent performance, rather than a random amount based on typing speed.
For example, if you don't want it to use more than say 1GB RAM (for web requests, not including overhead for the server/OS/etc) then you could turn performance info on and look for the typical memory usage of quiz start pages. Say it's 128MB, then set your server's max connections to 8.
The difference over standard behaviour is, say if your server can handle 20 quiz start requests at once and they all take 10 seconds, or it can handle 10 at once and they all take 5 seconds. Limiting the number of requests passed on by the server to 10 doesn't reduce the total amount of work done by the server but it does improve the average performance: 10 people have to wait 5 seconds, then the other 10 have to wait 10 seconds (5 in Apache queuing their request, another 5 in actual processing), instead of everyone having to wait 10 seconds. It also halves memory consumption.
Has anybody tried this kind of approach? I suspect it requires careful tuning and might break things but it seems a lot less hacky. Basically, I think the way people are running Moodle on a small server might be effectively making a promise - 'Hey Apache, I can handle 20 simultaneous requests, bring it on!' - which the server can't really deliver.
--sam
