Server memory configuration

Hello, Does anyone know how to increase the Web-CAT server memory to handle submission for 150 students?  My server hung up every time when my students submitted their work during class.






Stephen Edwards

There are multiple issues to

There are multiple issues to consider here.

First, the most direct answer is that Web-CAT's server memory availability is determined by the memory settings for the servlet container it is deployed in. Assuming you're running Tomcat, you need to check your Tomcat configuration to determine what memory settings are in effect. Depending on the OS you are running on, and whether you installed a stock version of Tomcat from the Tomcat web site vs. using a package manager, the configured memory amounts may be different. For many default installs, the memory limits are insufficient.

Basically, changing these involves adding -Xms and -Xmx JVM command line arguments to the Java command used to launch Tomcat.  You can google these java command line arguments for more details--basically, -Xms specifies the starting memory size for the JVM's heap space, and -Xmx specifies the maximum size it will be allowed to grow to. Again, where you add these depends on the OS and how Tomcat is deployed. If your server has sufficient memory, I'd recommend providing a starting = max = 1GB (or even 1.5GB), e.g., "java -Xms1g -Xmx1g ...", which means the JVM will initially allocate the full 1GB of heap space, but it will never grow. Note that the way the JVM works, there is always a maximum limit beyond which the heap will never grow.  The defaults when you don't specify any command line arguments are too small for Web-CAT.

Now, on to more complicated issues. Optimizing your Tomcat configuration for your particular server encompasses many other issues besides the memory limits on the JVM running Tomcat. You also need to consider how many cores your server has, how many threads within Tomcat you need to support, how MySQL is configured, and how all programs on your server (including Tomcat and its threads, MySQL and its threads, the grading jobs being executed by Web-CAT, which are independent of Tomcat's config, and any other server-side software regularly running that needs CPU resources) compete with each other for the cores you have available. Tomcat and its threads primarily handle the UI and main server-side functionality, but rely on the underlying database for retrieving information necessary to generate pages. Tomcat also uses one or more separate non-UI threads to handle grading student submissions. If you don't plan out how many Tomcat threads you expect to be working concurrently and make sure it is a reasonable number for your hardware, you can end up in situations where the whole system appears really, really slow, because too few threads are busy with user requests and other requests can't be processed ... or you can end up with the opposite problem, where too many threads have been created, and time slicing among all of them actually reduces effective throughput to a crawl.

From your description, it sounds like Tomcat is choking because of insufficient memory and/or threading configuration problems--limiting the number of active request-response threads in Tomcat to a reasonable number, and allowing other concurrent requests to queue up, may also be an important consideration for the situation you describe.

Finally, it turns out that it takes a fixed amount of time to process each student submission, which varies depending on your server hardware (usually between 5-15 seconds per Java submission, but varies depending on the language being processed, the server's hardware, the server's config, etc.). In the worst case, if you have 150 students submitting at exactly the same time, let's say, then it might take 12.5-37.5 minutes (that is, 5*150 - 15*150 seconds) to generate results ... and that's for just one submission per student.  If your average student wait for feedback is 6-19 minutes, you're going to have a frustrated crowd.

One of the main limiting factors here is the JVM startup time.  The number of independent JVM starts for processing a single Java submission is noticeable, and is the primary reason for the 5s+ processing times for each job. However, you really do have to take this into account if you expect for 150 students to be working live on the same task at the same instant.

Instead, it is important to look at the processing times for individual submissions and do some basic estimations on what kind of throughput you expect you might be able to achieve, vs. what kind of throughput is required for the situation you're trying to create in the classroom, and figure out where the main points of leverage are for moving the first one closer to the second one ... or work harder to manage expectations in the classroom.

That being said, if you're running on a beefy server (where you've got dual 16-core processors or something), let me know and we can talk about parallel execution of the backend--that is, having Web-CAT grade multiple submissions in parallel.  That's something we do on our production servers where we handle thousands of submissions per day, but that isn't an ideal solution for typical low-end hardware (i.e., single-chip 4-8 core machines), which are too busy handling the concurrency in the front end and database to deal with the heavy load of back-end parallelism.