I love it when a plan comes together. --Col. John "Hannibal" Smith, "The A-Team"
In our roles as consultants, teachers, and mentors to software developers, we see too many software products that fail to meet their performance objectives when they are initially constructed. Fixing these problems is costly and causes schedule delays, cost overruns, lost productivity, damaged customer relations, missed market windows, lost revenues, and a host of other difficulties. In extreme cases, it may not be possible to fix performance problems without extensive redesign and re-implementation. In those cases, the project either becomes an infinite sink for time and money, or it is, mercifully, canceled.These problems can be prevented by the systematic application of a few simple performance analysis and prediction techniques. Over the years, we have helped many clients produce software that meets performance objectives and is delivered on time and within budget. This book was produced in response to requests from our clients and students to provide a reference to the techniques that we have used and taught so successfully.
Objectives
By applying the material in this book you will be able to answer questions such as:
- Will your users be able to complete their tasks in the allotted time?
- Are your hardware and network capable of handling the load?
- Will your system scale up to meet the future demand?
More importantly, you will be able to answer these questions before you have committed a lot of time and money to an implementation, only to find that the answers are an emphatic (and expensive) no!
You will learn enough from this book to begin to apply these techniques immediately to manage the performance of your software systems. You will sharpen your skills as you use them on a variety of projects that include Web-based applications, distributed systems, real-time systems, traditional database applications, and others.
Software Performance
Performance is any characteristic of a software product that you could, in principle, measure by sitting at the computer with a stopwatch in your hand. The dimensions of performance include responsiveness (response time or throughput) and scalability.
How do projects get in trouble with performance? The problem is often due to a fundamental misunderstanding of how to achieve performance objectives. The approach is frequently "First, let's make it run; then, we'll make it run fast." The idea is to get the functionality right, and then tune for performance. Unfortunately, by the time the architecture and design are selected, it may already be too late to achieve adequate performance by tuning. It is a mistake to treat a potential performance problem as if it were of the same complexity as a coding error. Coding errors are relatively easy to fix, whereas performance problems may require extensive changes to code.
The proper way to manage software performance is to systematically plan for and predict the performance of the emerging software throughout the development process. This book presents a set of simple techniques that you can use to manage the performance of your software. These techniques do not require an advanced degree in mathematics, nor do they take significant amounts of time away from development activities. By applying them, you will be able to make informed choices among architectural and design alternatives, and proceed with confidence, knowing that your software will meet its performance objectives.The approach to managing performance presented here is unique. It has grown out of more than 10 years of collaboration between the authors that combines knowledge and experience in both software performance engineering and architectural analysis. Other authors have proposed elaborate modeling techniques that either aren't useful for real systems or require a Ph.D. in mathematics to apply. Our approach is practical, useful by non-specialists, and rigorous.
Software Performance Engineering
The techniques presented in this book are collectively known as software performance engineering (SPE). SPE is a comprehensive way of managing performance that includes principles for creating responsive software, performance patterns and antipatterns for performance-oriented design, techniques for eliciting performance objectives, techniques for gathering the data needed for evaluation, and guidelines for the types of evaluation to be performed at each stage of the development process.
SPE is model-based. Modeling is central to both SPE and object-oriented development. By building and analyzing models of the proposed software, we can explore its characteristics to determine if it will meet its requirements before we actually commit to building it. SPE uses models to quantitatively assess the performance of the emerging software. This book discusses how to quickly and easily create those quantitative models from the architecture and design models that you produce as part of the object-oriented development process. It also describes how to integrate SPE seamlessly into the overall object-oriented development process.
Finally, these techniques are neither new nor revolutionary. They have evolved from a relatively long history of proven quantitative disciplines. Nor are they a silver bullet. They must be used to be effective, and it will take some time to learn to apply them, particularly on your initial project. The amount of time required, however, is not excessive and is appropriate for most projects in their early stages. We have found that when problems are inevitable, your choice is "pay a little now (for the scalability and performance that you need) or pay much more later." Software metrics show that it costs up to 100 times more to fix problems in code than it does to fix problems in the architecture before code is written. The only way to determine whether problems are inevitable is to use the quantitative techniques described in this book early.
Who Should Read This Book
This book is primarily intended for experienced software developers who have used object-oriented techniques on one or more development projects and who are ready for the next step: to learn how to create software systems with built-in scalability and performance. The emphasis is on how to apply the techniques.Other readers will also find information that they can use:
- Project managers will find techniques that they can bring to their projects immediately to improve the way performance is managed. They will also learn how to implement SPE.
- Developers who are new to object-oriented techniques will discover how it is possible to manage performance for object-oriented systems, and find guidelines for creating responsive software that will augment their study of object-oriented development.
- Performance engineers will learn how to adapt their skills to object-oriented systems, as well as discover new approaches that are applicable to other development technologies.
- Students will learn about performance issues that arise in realistic, large-scale software systems and how to solve them.
Familiarity with object-oriented concepts is helpful, but it is not essential. We explain the portions of the Unified Modeling Language (UML) notation useful for performance assessments. If you find you would like more background, refer to other books in the Object Technology Series. 1
Familiarity with performance modeling techniques is helpful but it is not essential. We assume that you will use an SPE tool, such as SPE·ED , to evaluate your systems. We explain enough of the modeling fundamentals for you to become familiar with how such tools work. References are included with the material in case you would like to learn more about the modeling technology.
Organization of This Book
This book is organized into the following seven parts:
- Part I: Introduction and Overview provides an introduction to SPE and an overview of the modeling techniques
- Part II: SPE Models describes details of the models used in SPE and their solutions
- Part III: Data Collection discusses how to obtain SPE data, and provides some background on performance measurement techniques.
- Part IV: Performance Solutions presents techniques for designing performance into software systems, and maintaining performance throughout the life cycle
- Part V: Applications illustrates the application of SPE techniques to some important types of application domains
- Part VI: Making SPE Happen discusses how to implement SPE in your development organization
- Part VII: Appendixes summarize the notation used throughout the book.
How You Should Read This Book
Different people will have different reasons for reading this book and different needs for the information in it. The table below offers a suggested road map for reading the material that is keyed to several types of reader interests. The types of readers represented in the table are
- Developer--You are responsible for software development and need to make sure that your code meets performance objectives. You need to know it all: what SPE is, what it can do for you, how to construct and evaluate the models, how to design performance into your software, and how to fit SPE into the development process.
- Manager--As a manager, you need to know what SPE is, what it can do for you, and how it fits into the software development process. The modeling details are less important.
- Performance Engineer--You are responsible for working with developers to assist with the quantitative analysis of their systems. You also need to know it all: how to explain the SPE and what it can do for developers, how to construct and evaluate the models, how to identify and explain performance solutions and performance problems, and how SPE fits into the development process.
- Firefighter--You have a system that has performance problems and need help to get out of trouble. Later, when things calm down, you can go back and apply the SPE techniques to prevent these problems in future systems.
- Academic--The material in this book can be used as the basis for a graduate-level course in software performance engineering. The sections on integrating SPE into the software process and implementing SPE are probably less important, however.
The entries show the priority or importance of each part of the book for the various reader interests with letters (A is vital, B is important, C is some value). The numbers indicate the order in which the parts should be read (1 is first, 2 next, and so on).
Reader's Guide
| Part I | Part II | Part III | Part IV | Part V | Part VI |
Developer | A1 | A2 | A3 | A4 | A5 | A6 |
Manager | A1 | C1 | B1 | B2 | B3 | A2 |
Performance Engineer | A1 | A2 | A3 | A4 | A5 | A6 |
Firefighter | A1 | A4 | A2 | A3 | A5 | B1 |
Academic | A1 | A2 | A3 | A4 | A5 | B1 |
Formatting Conventions
Points, observations, and guidelines that are especially important are italicized and highlighted by a pointing hand in the margin.
Presentation of one topic often includes a reference to another that is discussed elsewhere. To help in making the connection, cross-references are provided in the left margin.
Asides, parenthetical comments, and general guidelines are set apart as notes.
Execution graphs are similar to program flowcharts, but they are not the same. Execution graphs show the frequency of path execution, and model only those paths that are key to performance.
Examples and other portions of the text that are important but might interrupt the general flow are set apart.
SPE on the Web
The models in this book and a demonstration version of the SPE·ED tool are on the Web at http://www.perfeng.com/PerfSolutions/models. Other information about SPE is at http://www.perfeng.com. There is an online discussion group on SPE at http://www.egroups.com/group/softwareperfeng/. If you discover errors in this book, please email them to [email protected]. We will periodically post them to http://www.perfeng.com/PerfSolutions/errata.
Connie U. Smith
Santa Fe, NM
May 2001
Lloyd G. Williams
Boulder, CO
May 2001
1For object-oriented concepts, see: G. Booch, Object-Oriented Analysis and Design with Applications, Redwood City, CA, Benjamin/Cummings, 1994. For UML, see G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Reading, MA, Addison-Wesley, 1999.
0201722291P09102001