Performance Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 144

9.5.5 Saturday Workload Showstopper Corrections, We Think

At this point in our discussion, we receive the corrected, functionally regressed software
ready for performance workload retesting. We learn from the code correction log and
discussions with the developers that the logon code modules experienced interference
from the purchase steps at 400 active users because the memory area allocated for user
IDs and passwords began to “leak” into the purchase step execution area. We also learn
from the same sources that the purchase steps and catalog browse code modules shared
a set of utility routines in a common dynamic library that began to degrade the perfor-
mance of both modules by the way the utility routines were loaded for execution.
Our next step is to rerun the individual transaction groups in an empty test system to ver-
ify that the performance fi xes did not, in fact, slow down the code. Figures 9.9-9.11 show the
results of our empty system ramp-up performance measurements in an empty test system.

Log on

4

3.5

Max response time = 3 s

3

2.5

2

1.5

1 50 100 150 200 250 300 350 400 450 500

Number of round trip transactions

Figure 9.9 Round trip performance for peak logon workload after performance corrections have

been applied

Purchase

8

Max response time = 7 s

7

6

5

4

3

2

1 50 100 150 200 250 300 350 400 450 500

Number of round trip transactions

Figure 9.10

Round trip performance for peak purchase workload after performance corrections have

been applied