Using the Test Results

Load testing generates large volumes of data that must be sorted and organized before it offers meaningful insight into service performance. A series of predefined reports and graphs are essential for getting started; reports should be easily customized as testers gain experience and understand what information is most useful to them. The iterative nature of load testing also requires easy comparisons between tests to identify the differences associated with any changes.

Testing produces information that is useful to different groups. One advantage of distributing this data widely is that it provides a common context for discussions between groups that do not usually cooperate well. Load testing should produce a set of results for planners, developers, and administrators.

Planners use the load testing information to project future resource demands. They want to remain on the linear side of the inflection point. Knowing the normal growth in loading gives an estimate of the time to act before the inflection point is reached. Having accurate information about the contributions of specific components to overall response time allows accurate investments and optimum returns.

Developers use load testing as feedback on the soundness of their designs and their use of best practices. They are able to determine if the application meets basic performance, stability, and reliability needs. Tracking the number of failed transactions is also critical. High transaction volume at the edge of the performance envelope counts as success only if the transactions are actually completing as expected. Developers need to know if fast transaction execution actually masks failures within each attempt.

Load testing data also assists administrators with setting realistic thresholds and with adjusting operations throughout a business cycle. The relationship of the inflection point to the negotiated SLA must be evaluated. For example, if the required response time lies well within the linear domain, to the left of the inflection point, there is a high probability that delivered services will be compliant. In contrast, if the service will be operating in the nonlinear part of its performance envelope, to the right of the inflection point, compliance is likely to suffer.

Alarm thresholds can be set as a result of load tests and their determination of the inflection points. As loading or response times approach the inflection point, the system can be configured to issue an alert with a high severity level. A warning alert can be generated at lower loading and response levels to give the operations team some lead time before instability occurs. These alerts can be incorporated into automated operations or policy systems (as discussed in Chapter 7, "Policy-Based Management") so that actions such as redirecting traffic to other sites or bringing more resources online can be initiated automatically as performance moves toward the inflection point.

Load testing results can also be used to make modeling tools more accurate and effective, as discussed in Chapter 12.