Project

PC2 V10 performance test framework

Project (M.S., Computer Science)--California State University, Sacramento, 2018.

The PC2 Contest Control System provides for the ability of teams in a programming contest to submit runs – that is, programs which are attempts at solving a contest problem specified by the contest judges. In Version 10 (V10) of PC2, runs are submitted via web pages served by a webserver embedded in a module called the AppServer. On the server-side, AppServer automatically inserts a submitted run into a database. The Dispatcher queues run notifications and makes them available to another module called the Checker. Checker returns the result to the Dispatcher that whether run correctly solved the problem or not. The Dispatcher in turn forwards the result to the AppServer for subsequent display to the team which submitted the run. There is a Resource Manager which supports the ability of the Contest Administrator to define multiple different contests and to enter contest configuration information for each defined contest. The architecture allows only a single Dispatcher and a single Resource Manager to be running at any given time. Each V10 module runs on its own separate machine.
 
 There are some limitations in the current system. A fundamental premise of the PC2 V10 system is that it is intended to handle large numbers of teams simultaneously participating in multiple different contests. The problem is that there is currently no mechanism for testing the performance of the system under such a large load and verify the performance capabilities of the V10 system.
 The proposed solution includes several important points. 
 A. Build a large collection of programming contest problems and corresponding run submissions.
 B. Investigate a variety of available performance and load-testing tools.
 C. Implement a framework for submitting the collection of contest problems and corresponding submissions to PC2 V10 and monitoring the resulting performance using the selected tool(s).
 D. In the event that Jetty is found to be unable to support the desired load, investigate and propose mechanisms for substituting alternative webservers into V10 (e.g, using the nGinX webserver).

The PC2 Contest Control System provides for the ability of teams in a programming contest to submit runs – that is, programs which are attempts at solving a contest problem specified by the contest judges. In Version 10 (V10) of PC2, runs are submitted via web pages served by a webserver embedded in a module called the AppServer. On the server-side, AppServer automatically inserts a submitted run into a database. The Dispatcher queues run notifications and makes them available to another module called the Checker. Checker returns the result to the Dispatcher that whether run correctly solved the problem or not. The Dispatcher in turn forwards the result to the AppServer for subsequent display to the team which submitted the run. There is a Resource Manager which supports the ability of the Contest Administrator to define multiple different contests and to enter contest configuration information for each defined contest. The architecture allows only a single Dispatcher and a single Resource Manager to be running at any given time. Each V10 module runs on its own separate machine. There are some limitations in the current system. A fundamental premise of the PC2 V10 system is that it is intended to handle large numbers of teams simultaneously participating in multiple different contests. The problem is that there is currently no mechanism for testing the performance of the system under such a large load and verify the performance capabilities of the V10 system. The proposed solution includes several important points. A. Build a large collection of programming contest problems and corresponding run submissions. B. Investigate a variety of available performance and load-testing tools. C. Implement a framework for submitting the collection of contest problems and corresponding submissions to PC2 V10 and monitoring the resulting performance using the selected tool(s). D. In the event that Jetty is found to be unable to support the desired load, investigate and propose mechanisms for substituting alternative webservers into V10 (e.g, using the nGinX webserver).

Relationships

Items