- Software and Performance
- 2 The Importance of Performance
- 3 How Should You Manage Performance?
- 4 Software Performance Engineering
- 5 SPE for Object-Oriented Systems
- 6 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Software Performance Engineering
Software performance engineering is a systematic, quantitative approach to constructing software systems that meet performance objectives. SPE is an engineering approach to performance, avoiding the extremes of performance-driven development and "fix-it-later." SPE uses model predictions to evaluate trade-offs in software functions, hardware size, quality of results, and resource requirements.
The "performance balance" in Figure 1-2 depicts a system that fails to meet performance objectives because its resource requirements exceed computer and network capacity. With SPE, you detect these problems early in development, and use quantitative methods to support cost-benefit analysis of hardware solutions versus software requirements or design solutions, versus a combination of the two. You implement software solutions before problems are manifested in code; organizations implement hardware solutions before testing begins. The quantitative assessment identifies trade-offs in software functions, hardware size, quality of results, and resource requirements.
){kind=link}
Figure 1-2: Performance Balance
SPE is a software-oriented approach: it focuses on architecture, design, and implementation choices. The models assist developers in controlling resource requirements by enabling them to select architecture and design alternatives with acceptable performance characteristics. The models aid in tracking performance throughout the development process and prevent problems from surfacing late in the life cycle (typically during final testing).
SPE also prescribes principles for creating responsive software, performance patterns and antipatterns for performance-oriented design, the data required for evaluation, procedures for obtaining performance specifications, and guidelines for the types of evaluation to be conducted at each development stage. It incorporates models for representing and predicting performance as well as a set of analysis methods [Smith 1990].
SPE is neither a new nor a revolutionary approach. It applies proven techniques to predict the performance of emerging software and respond to problems while they can be fixed with a minimum of time and expense.
We have found that, with SPE, it is possible to cost-effectively engineer new software systems that meet performance goals. By carefully applying the techniques of SPE throughout the development and integration process, it is possible to produce new systems that have adequate performance and exhibit the other qualities that have made object-oriented techniques so effective, such as reusability, relatively rapid deployment, and usability.
With SPE, you should be able to answer the following questions early in development:
- Will your users be able to complete tasks in the allotted time?
- Are your hardware and network capable of supporting the load?
- What response time is expected for key tasks?
- Will the system scale up to meet your future needs?
1.4.1 SPE Modeling Strategies
The use of these strategies is illustrated in Part II.
SPE uses several modeling strategies to obtain results quickly, to cope with uncertainty in estimates of software and hardware resource usage, and to control costs.
The Simple-Model Strategy
The simple-model strategy leverages the SPE effort to provide rapid feedback on the performance of the proposed software.
NOTE
Start with the simplest possible model that identifies problems with the system architecture, design, or implementation plans.
The early SPE models are easily constructed and solved to provide feedback on whether the proposed software is likely to meet performance goals. These simple models are sufficient to identify problems in the architecture or early design phases of the project. You can easily use them to evaluate many alternatives because they are easy to construct and evaluate. Later, as more details of the software are known, you can construct and solve more realistic (and complex) models.
The Best- and Worst-Case Strategy
The models rely upon estimates of resource requirements for the software execution. The precision of the model results depends on the quality of these estimates. Early in the software process, however, your knowledge of the details of the software is sketchy, and it is difficult to precisely estimate resource requirements. Because of this, SPE uses adaptive strategies, such as the best- and worst-case strategy
NOTE
Use best- and worst-case estimates of resource requirements to establish bounds on expected performance and manage uncertainty in estimates.
For example, when there is high uncertainty about resource requirements, you use estimates of the upper and lower bounds of these quantities. Using these estimates, you produce predictions of the best-case and worst-case performance. If the predicted best-case performance is unsatisfactory, you look for feasible alternatives. If the worst-case prediction is satisfactory, you proceed to the next step of the development process with confidence. If the results are somewhere in between, the model analyses identify critical components whose resource estimates have the greatest effect, and you can focus on obtaining more precise data for them.
A variety of techniques can also provide more precise resource estimates, including: further refining the design and constructing more detailed models, or constructing a prototype or implementation of key components and measuring resource requirements.
The Adapt-to-Precision Strategy
As the simple-model strategy states, simple models are appropriate for early life cycle studies. Later in the development process, SPE uses the adapt-to-precision strategy.
NOTE
Match the details represented in the models to your knowledge of the software processing details.
As the design and implementation proceed and more details are known, you expand the SPE models to include additional information in areas that are critical to performance.
1.4.2 SPE Models
The SPE models are similar to those used for conventional performance evaluation studies. In conventional studies (of existing systems), capacity planners model systems to predict the effect of workload or configuration changes. The conventional modeling procedure is as follows:
Study the computer system.
Construct a system execution model (usually a queueing network model).
Measure current execution patterns.
Characterize workloads.
Develop model input parameters.
Validate the model by solving it and comparing the model results to observed and measured data for the computer system.
Calibrate the model until its results match the measurement data.
Planners then use the model to evaluate changes to the computer system by modifying the corresponding workload parameters, the computer system configuration parameters, or both. Capacity planners rely on these models for planning future acquisitions. The model precision is sufficient to predict future configuration requirements; models are widely used, and they work, so we use them as the basis for SPE.
Figure 1-3: Conventional versus SPE Models
){kind=link}
SPE performance modeling is similar. However, because the software does not yet exist, and we do not want to wait for measurements of the software, we first model the software explicitly. Figure 1-3 illustrates the difference between conventional models and SPE models. With conventional models, we are concerned with modeling workloads that already exist. The system execution model quantifies the effects of contention for computer resources by different types of existing work. With SPE, we want to include software that does not yet exist. To do this, we introduce a new type of model: the software execution model. The software execution model represents key facets of the envisioned software execution behavior. Its solution yields workload parameters for the system execution model that closely resemble the conventional models.