Cnetics produces and tunes the Banner system of a major university without interrupting the production environment.

Objective: The IT department of a university was recently given the challenge of determining the cause of sporadic slowdowns to their SCT Banner system. Much of the time the application performed quickly and users did not experience system slowdowns. At other times, however, the Banner system slowed down, user screens timed out, and class registration time went from a few seconds to over a minute. Faculty and students became increasingly frustrated.

In an attempt to solve the problem, the IT staff purchased monitoring and tuning software modules to examine performance. They also brought in consultants to diagnose the system problems. Unfortunately, their tuning efforts were expended on a system that was not experiencing heavy workload.

The monitoring tool did capture heavy workload and that workload was analyzed; yet no changes were made during the heavy workload period because the Banner system had to be available. Moreover, when they used the monitoring tools under heavy workloads, they were unable to make tuning changes because the system was in a production mode.

For the purpose of loading up the system for further analysis, the IT staff set up a registration simulation in a classroom using faculty members. Unfortunately, the simulation did not create enough workload.

These performance-tuning efforts failed because:

IT staff were “flying blind'’ in trying to correct these predictable but unidentified performance problems.

With the problem still unsolved, the university was only able to register 300 students per day during a subsequent late registration process.

Solution: Even more frustrated, the university called on Cnetics Technologies to find and solve the problem. Our strategy was different–to find and solve the problem, we had to first reproduce the problem. What did Cnetics do differently? We produced and tuned the Banner system without interrupting the production environment.

In order to create an adequate load test, we interviewed university staff to find out what application activities occur during heavy workload. University staff provided Cnetics approximate totals for each of the activities. Questions asked included: how many students were registering for a class at the same time? How many students were performing a class search at any given time? How many faculty members were reviewing their rosters during registration?

Armed with this information, Cnetics deployed software scripts to simulate the workload encountered during busy times. Once the software was configured and the scripts completed, each individual virtual user simulated active users of the Banner system.

While creating workload, Cnetics trapped system metrics on the network, application server and database software, the application server machine and database machine. Most importantly, the response time of the virtual user was tracked via the automated load-testing tool.

As the workload increased, bottlenecks became obvious. For example, when the response time began to average beyond 10 seconds, the system components were examined to see which one(s) were overloaded. Adjustments were then made to the bottleneck component and the same test was run again to see if performance improved. Iterations of this workload testing and adjustment continued until hardware limits were reached.

Results: Cnetics’ methodical analysis and adjustments to the system were successful in finding and relieving many configuration bottlenecks. The university was then shown which components were problems and which were not contributors to the previous sluggish system performance. The university also has quantified values for how much workload the Banner system can handle during peak usage. Cnetics also made recommendations for hardware changes to improve peak load throughput. Their SCT Banner system now can handle heavier workload during peak usage.