9.4 Techniques for SPE

As the example discussed in the previous sections indicate, SPE techniques should be integrated into the software development life cycle. Several methodologies for software development have been proposed and used successfully in the software industry. Consider, for example, the waterfall model, introduced by Boehm [2], which decomposes the software development life cycle into five main phases: requirement analysis and specification, system design, program design, program coding, and system testing. Fig. 9.9 illustrates these various phases and the relationships between each phase.

Figure 9.9. Waterfall model of software development.

The requirement analysis and specification phase describes the problem to be solved by the new software. As a result of this phase, two types of requirements are generated: functional and non-functional requirements. The functional requirements describe the activities that the new system is supposed to perform. The non-functional requirements include SLAs on response times, throughputs, and availability, as well as a specification of the target hardware/software platform. This includes a specification of the processors, storage devices, operating system, database management system, transaction processing monitors, and middleware, of the target hardware/software platform.

The system design phase describes the solution to the problem specified in the previous requirements phase. The system is decomposed into modules and pseudo code for each module is generated. The relationship between modules is established and the type of data used by each module is specified. The number of invocations per module are derived from the system design. This allows a first approximation of the service demands. Performance predictions obtained with SPE data collected during this phase should be within 30% of the actual performance of the fully implemented application [16].

The third phase, program design, describes the mechanisms that best implement the solution. Algorithms and data structures are specified in this phase. Each of the modules resulting from the system design phase is mapped into one or more programs. A complete specification of each transaction is given in this phase. This specification is generally given in some form of pseudocode and is independent of the target programming language. Clisspe is appropriate in this phase. More precise estimates of the transaction service demands may be obtained in this phase since the number of I/O operations and/or DBMS calls can be derived from the transaction descriptions. The accuracy of the predictions obtained in this phase is expected to be in the range 15 to 20% [16].

The actual implementation occurs during the program coding phase. This phase is used to refine the I/O and CPU service demands for the various transactions as they are implemented. Test experiments of each transaction type on the target software/hardware platform are possible. These yield accurate values for I/O and CPU demands.

The final phase is system testing. In this phase, an overall verification of I/O and service demand estimates is performed. Validation of performance predictions made by the models is possible.

Each phase of the software development life cycle increases the level of accuracy of the service demand estimates. The initial models developed during the early stages of the design can only be expected to provide gross order-of-magnitude performance predictions. Gunther indicates that progressively more accurate data can be captured in each phase of the software development life cycle using the spiral methodology for software development [6].

9.4.1 Obtaining Data for SPE

Application sizing involves cooperating with people from several departments, mainly the developers. This may pose problems of a managerial nature. Developers must appreciate and value the importance of SPE so that they assign it enough importance and give priority to it [16]. Numerous approaches can be used to obtain cooperation from people that should provide data for SPE [7] .

The primary difficulties in obtaining the proper data may arise from [16]:

• Inadequate communication between designers and performance engineers.

• Low priority given by designers to obtain and provide SPE data.

• Inadequate understanding by designers of the relevant SPE data.Some data parameters are more important than others and designers are not always aware of which parameters will affect performance most. For instance, the volume of physical I/O is an important factor in determining service demands at the peripherals and at the CPU.

It should also be realized that not all transactions will have a relevant impact on performance. In fact, as observed by practitioners [5, 15], more than 80% of user requests result in less than 20% of the transactions. This 80-20 rule of thumb calls for giving priority to obtaining SPE data for the 20% most frequent transactions.

Whenever there is a high degree of uncertainty over the value of a given service demand or workload intensity parameter, the use of best-case and worst-case analysis is appropriate [15]. In the process of refining the estimates, resources that have the greatest impact on performance should be identified. It is important to concentrate most of the effort in trying to obtain better estimates for the key parameters [15].

The service demand, D_i,r, of class r transactions at device i is estimated as follows in an SPE study:

Equation 9.4.7

where

• S_i,r is the set of all statements that contribute to the service demand of transactions of class r at device i

• n_s is the average number of times that statement s is executed

• p_s is the probability that statement s is executed

• is the average service demand at device i for class r due a single execution of statement s

The flow of control of each transaction or application determines the average number of times that a certain portion of the code is executed. For example, the analysis of a specification of a transaction in Clisspe allows for the easy computation of n_s and p_s through the nesting of loops and through branching statements [10]. can be obtained from simple experiments.