- 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.3 How Should You Manage Performance?
Are you managing software performance reactively or proactively?
1.3.1 Reactive Performance Management
Do any of these sound familiar?
"Let's just build it and see what it can do."
"We'll tune it later; we don't have time to worry about performance now."
"We can't do anything about performance until we have something running to measure."
"Don't worry. Our software vendor is sure their product will meet our performance goals."
"Performance? That's what version 2 is for."
"We'll just buy a bigger processor."
"Problems? We don't have performance problems."
If so, you're probably managing software performance reactively. Reactive performance management waits for performance problems to appear, and then deals with them in an ad hoc way.
Reactive performance management is just the "fix-it-later" approach in another guise. It has the same risks of cost overruns, missed deadlines, and project failure.
1.3.2 Proactive Performance Management
Proactive performance management anticipates potential performance problems and includes techniques for identifying and responding to those problems early in the process. There are several characteristics of proactive performance management:
The project has a performance engineer responsible for tracking and communicating performance issues.
Everyone on the project knows the name of the performance engineer.
There is a process for identifying performance jeopardy (a danger of not meeting performance objectives) and responding to it.
Team members are trained in performance processes.
The project has an appropriate performance risk management plan based on shortfall costs and performance engineering activity costs.
With Software Performance Engineering (SPE), proactive performance management identifies and resolves performance problems early, avoiding the negative effects of the "fix-it-later" approach.
Historically, performance was managed either proactively or by relying on the hardware and support software to resolve problems. In the early days of computing, developers had no choice but to manage the space and time required by their software. Later, innovations in hardware and operating systems provided some relief, and developers began to worry less about performance. "Fix-it-later" was first advocated at this time. Software performance engineering techniques were originally proposed when performance failures due to the reactive "fix-it-later" approach first emerged.
As new technologies appeared, the learning curve for those technologies again required careful management to prevent performance problems. Once the performance aspects of the new technology were understood and the hardware and support software provided new features to accommodate the technology, developers could again rely more on the hardware and support software. This process repeats as other new technologies are introduced, and the hardware and support software solutions catch up with them.
NOTE
The use of new software technology requires careful attention to performance until the performance aspects of the new technology are understood.
Note that the "new" technology is not necessarily "bleeding edge" technology—it might just be new to you. If you don't have experience with the technology and the performance intuition that comes with it, the result is the same.
Distributed systems challenge performance intuition. Constructing them involves a complex combination of choices about processing and data location, platform sizes, network configuration, middleware implementation, and so on. Managing the performance of these distributed software systems will likely always call for quantitative assessment of these alternatives.
NOTE
Intuition about performance problems is not sufficient; quantitative assessments are necessary to assess performance risks.
We have been seeing a phenomenon more and more frequently: as organizations adopt technologies with which they have little experience, such as Web applications, Common Object Request Broker Architecture (CORBA), or Enterprise JavaBeans, they have more performance failures. When using an unfamiliar technology, you are in a situation that requires proactive performance management.
NOTE
If you are managing performance reactively on systems that use unfamiliar technology, your probability of experiencing a performance failure is much higher.