Banner Response Time Improves

Since January, the Banner team has been focusing on the puzzling problem of GUI Banner's slow response time. Some users had voiced concerns about the system's performance since the graphical user interface (GUI) version was implemented last December. After months of investigation and troubleshooting, the team is reporting major improvements in the system's performance. Response times now range from 2 to 5.2 seconds, as measured on a small sampling of high use Banner forms (See Chart 2). By comparison, response times for the same sampling of forms ranged from 4 to 23 seconds in March (See Chart 1).

Chart showing that Banner response time ranged from 4 to 23 seconds in March 1998

Chart 1: Banner response time ranged from 4 to 23 seconds in March.

Chart showing that Banner response time ranged from 2 to 5.2 seconds in May 1998, indicating a drastic improvement over response times observed in March 1998
Chart 2: Banner response time ranged from 2 to 5.2 seconds last May, indicating a drastic improvement over response times observed in March (see Chart 1).

In early February, despite efforts to clean up bugs and Oracle software pieces, the problem with Banner's response time persisted. The team monitored the network looking for bottlenecks, checked the Banner host computer (Zeus) for processing or memory stress, and the Banner database for any signs of stress. The team also visited various departments to observe difficulties with the Banner forms. These visits yielded a wide range of response times, so the team decided to establish benchmarks in various locations around campus.

Using a problem solving method developed by Kepner-Tregoe, Inc., a global management consulting firm, the team set out to isolate the problem and test for a possible solution. Solving Banner's slow response time was made all the more difficult because there are so many facets to the system -- so many potential points of failure. There had been concern that the production host computer may have had faulty processor chips, but Sequent, Inc. verified that the floating point problem observed in older Intel chips did not affect these processor chips.

The team then focused its attention on the Citrix servers where the Banner forms reside. With over 1,200 forms, the team expected the search to be slow. As the newest additions to the Banner architecture, the Citrix servers were also considered possible points of failure although extensive monitoring of these systems showed no processing limitations. When comparing the code for one of the locally modified forms with the vendor's, a programmer discovered SCT had adopted design solutions which were different from UCD's. Once the team changed to the SCT design, the forms sped up to compare with the SCT forms. In April, performance improved even further following tuning enhancements to the Citrix WinFrame operating system.

This summer, the team will continue to explore the exact cause of the performance problem and other possible improvements. SCT, the vendor that supplies the Banner software, has pledged to work with the team until the response time has improved as much as is possible for GUI technology.

Sandra Stewart of Information Resources contributed to this article.