WeBWorK Main Forum

Estimating server load for online exams

Re: Estimating server load for online exams

by Danny Glin -
Number of replies: 0

Unfortunately when the Gateway Quiz mode was first built it was to serve a drop-in quiz model where there were typically not a large number of students starting at the same time, which is why many institutions are running into issues with large scale synchronous exams.

The thing that typically kills a WeBWorK server is running out of memory, which is what Edward experienced.  The way to mitigate this is to limit the number of simultaneous apache processes, and to try to limit the size of each process.

The master apache process doesn't typically grow over time, at least not to an extent where it becomes a memory hog.  The master process doesn't serve apache requests, so it doesn't suffer from the memory usage associated with serving PG problems.  The child processes are the ones that grow in memory usage, but there are a couple of ways to mitigate that.

Rendering a PG problem leads to some growth in the size of the apache child that does the rendering.  One of the issues with the gateway quiz module is that all of the problems on a page are rendered by a single process, which can lead to a significant ballooning of memory usage by that process.  The typical solution is to kill off these child processes frequently.  This is handled by the MaxConnectionsPerChild directive in the apache configuration.  I typically recommend setting this to 50 or 100, which means that a child will serve 50 or 100 requests before it is killed and a new process is spawned.  If your server is doing almost exclusively quizzes then it may make sense to go even lower.  The extreme would be to set it to 1, which would mean that a new child is spawned for every request.  This would likely almost solve the memory issue at the expense of an increase in processing/disk usage, as there is some overhead to create new processes.  It would likely mean that it would take longer for pages to load, but at least the server wouldn't end up thrashing.

Also make sure that MaxRequestWorkers is set appropriately for your server.  This is the maximum number of child processes that will be started at a time.  I typically budget 100MB to 200MB of RAM to each child process, but YMMV.  The lower this number the less likely you are to run out of memory, but it also means that fewer requests can be served at a time.

Please post your experiences here, as every institution uses WeBWorK slightly differently, so there isn't a one size fits all solution.