"Utterly demystifies the job (no longer the art) of performance engineering. Monsters, begone! Wizards, away! It leaves you feeling that you could really do this on your own. And, thanks to Connie and Lloyd, you can."--From the Foreword by Paul Clements
Performance, responsiveness, and scalability are vital aspects of today's software. Yet many software systems cannot be used as initially implemented because of performance problems. Such failures can translate into significant costs for software developers due to damaged customer relations, lost income, and time and budget overruns.Performance Solutions offers straightforward techniques and strategies that can be used by software developers, project managers, and performance specialists to handle the performance of software throughout the development process. In particular the book focuses on how to design performance into software systems early and then maintain performance throughout the software development life cycle.
Software Performance Engineering (SPE) is a systematic, quantitative approach to cost-effectively constructing software systems that meet performance objectives. This book details the various SPE models that can be used for a wide variety of applications, including Web-based and distributed systems. It describes effective data gathering and performance measurement techniques and explores the principles of performance-oriented design. You will also find practical guidance on implementing an SPE program. Specific topics of interest include:
Numerous real-world applications and case studies illustrate the application of SPE techniques to important application domains, including Web and embedded real-time systems.
With this book, you will gain the understanding and skills you need to make informed choices among architectural and design alternatives and create responsive, scalable software on time and within your budget.
Click below for Sample Chapter related to this title:
Foreword by Grady Booch.
Foreword by Paul Clements.
I. INTRODUCTION AND OVERVIEW.1. Introduction.
Software and Performance.
The Importance of Performance.
Consequences of Performance Failures.
Causes of Performance Failures.
Getting It Right.
How Should You Manage Performance?
Reactive Performance Management.
Proactive Performance Management.
Software Performance Engineering.
SPE Modeling Strategies.
SPE for Object-Oriented Systems.
What Does It Cost?
What Do You Need?
Summary.2: SPE Quick View.
SPE Process for Object-Oriented Systems.
Assess Performance Risk (Step 1).
Identify Critical Use Cases (Step 2).
Select Key Performance Scenarios (Step 3).
Establish Performance Objectives (Step 4).
Construct Performance Models (Step 5).
Determine Software Resource Requirements (Step 6).
Add Computer Resource Requirements (Step 7).
Evaluate the Models (Step 8).
Verify and Validate the Models (Step 9).
SPE in the Unified Software Process.
Summary.3: SPE and the UML.
Extending the UML.
Use Cases and Scenarios.
Extensions to Sequence Diagram Notation.
Looping, Alternation, and References.
Time in Sequence Diagrams.
Threads and Processes.
II. SPE MODELS.4: Software Execution Models.
Representing Software Execution Models.
Execution Graph Restrictions.
Basic Solution Algorithms.
More Advanced Solution Techniques.
Execution Graphs from Sequence Diagrams.
ICAD Case Study.
Analysis of Results.
Summary.5: Web Applications and Other Distributed Systems.
Distributed Object Technology.
Limitations of Distributed Object Technology.
Effective Development with Distributed Object Technology.
Modeling Distributed System Interactions.
Types of System Interactions.
Software Execution Model Representation.
Representing Middleware Overhead.
Software Model Solution Approximations.
Example: Web e-Commerce Application.
Order Process Scenario.
Summary.6: System Execution Models.
System Model Basics.
Solving the Queueing Model.
Networks of Queues.
Deriving System Model Parameters from Software Model Results.
Using the System Model for SPE.
Advanced System Models.
Alternate Solution Methods.
Distributed System Case Study.
III. DATA COLLECTION.7: SPE Data Collection.
SPE Data Requirements.
Key Performance Scenarios.
Software Resource Requirements.
Computer Resource Requirements.
Data Gathering Issues.
When to Conduct Performance Walkthroughs.
Tips for a Successful Performance Walkthrough.
Resource Estimation Techniques.
Use a Mentor.
Best-Worst Case Estimates.
What to Estimate.
Estimating I/O Requirements.
Estimating Network Messages
Obtaining Computer Resource Requirements.
Summary.8: Software Measurement and Instrumentation.
What Should You Measure?
Workload Data and Data Characteristics.
Software Resources and Processing Overhead.
Computer Resource Usage.
Planning for Performance Measurement.
Designing and Conducting Measurement Studies.
Performance Measurement Concepts.
Factors That May Affect Measurements.
Data Collection Techniques and Tools.
Data Collection Techniques.
Measuring SPE Data.
Instrumentation Design Considerations.
Application Resource Measurement.
IV. PERFORMANCE SOLUTIONS.9: Performance-Oriented Design.
Principles for Performance-Oriented Design.
Performance Control Principles.
Performance Objectives Principle.
Processing Versus Frequency Principle.
Shared Resources Principle.
Parallel Processing Principle.
Using the Principles.
Summary.10: Performance Patterns.
First Things First.
Slender Cyclic Functions.
Summary.11: Performance Antipatterns.
The “god” Class.
Excessive Dynamic Allocation.
Circuitous Treasure Hunt.
The One-Lane Bridge.
Summary.12: Implementation Solutions.
General Performance Solutions.
Fast Path Speed-Up.
Algorithm and Data Structure Choices.
Time Versus Space Trade-Offs.
Hardware/Software Platform Dependencies.
Performance Solutions for Object-Oriented Software.
V. APPLICATIONS.13: Web Applications.
SPE Models for Web Applications.
Case Study: Nachtfliegen.com.
Plan Itinerary Scenario.
Software Model Solution.
System Execution Model.
Sensitivity and Scalability Analysis.
Typical Performance Problems.
Summary.14: Embedded Real-Time Systems.
Embedded Real-Time Systems Background.
Real-Time Operating Systems.
Response Time and Throughput.
SPE Models for Embedded Real-Time Systems.
Case Study: Telephony Switching.
Architecture and Design.
Typical Performance Problems.
VI. MAKING SPE HAPPEN.15: The SPE Process.
The SPE Process.
Assess Performance Risk.
Identify Critical Use Cases.
Select Key Performance Scenarios.
Establish Performance Objectives.
Construct Performance Models.
Determine Software Resource Requirements.
Add Computer Resource Requirements.
Evaluate the Models.
Verify and Validate Models.
Late Life Cycle SPE Activities.
More Detailed Models.
More Precise Data.
Post-Deployment Performance Management.
Performance Management Plans.
Performance V&V Plan.
SPE Configuration Management Plan.
Execution Environment Specifications.
Performance V&V Reports.
Performance Test Plans.
Performance Test Results.
Integrating SPE Into Your Software Process.
The Waterfall Model.
The Spiral Model.
SPE in the Unified Process.
Summary.16: Implementing SPE.
SPE Adoption and Use.
Critical Success Factors for Adoption and Use.
SPE Implementation Strategies.
Who Pays for SPE?
Critical Factors for Successful Projects.
VII. APPENDIXES.Appendix A: UML Notation.
Use Case Diagrams.
Basic Sequence Diagrams.
Augmented Sequence Diagrams.
Stereotypes, Tagged Values, and Constraints.
Constraints.Appendix B: SPE Modeling Notations.
Execution Graph Notation.
Information Processing Graph Notation.Bibliography.
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.
By applying the material in this book you will be able to answer questions such as:
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.
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.
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.
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:
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.
This book is organized into the following seven parts:
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
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).
|Part I||Part II||Part III||Part IV||Part V||Part VI|
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.
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 perfSolutions@perfeng.com. We will periodically post them to http://www.perfeng.com/PerfSolutions/errata.
Connie U. Smith
Santa Fe, NM
λ, system arrival rate, 143
N, queue length, 144-145
RT, residence time, 144-145
S, mean service time, 143, 145
U, utilization, 143, 145
V, number of visits, 143
X, throughput, 143, 145
Numerics 80-20 rule, 171, 245, 311, 314-316, 411
A Action, 88
Activation, 54, 170
Active class, 62
Active object, 62
ActiveX Control, 344
Activity diagram, 52, 58, 73, 89
Adapter pattern, 344
Circuitous Treasure Hunt and, 301
Adapt-to-precision strategy, 19-20
Adopting and using SPE, 444-455
advocate, need for, 445, 453
commitment, obtaining, 445-446
credibility, 445, 459
credibility, building, 447, 454
economic justification, 448-449
key considerations, 448
organizational issues, 444-446, 451, 455-457
pilot projects and, 451-452
success factors, 440, 452-455, 459-461
success, credibility and, 445, 447, 459
teamwork, 446, 454
Advanced system model, 151-152, 346, 421
Alexander, C., 262
Alexander, R., 315
Algorithm and data structure choices, 322-323
Algorithm, random selection, 278
Almeida, V. A. F., 371
alt, 56, 65, 470
Alternate Routes pattern, 276-279
One-Lane Bridge and, 305
Alternation See alt
See System execution model
See Performance antipattern
Aperiodic event, 376
Approximate solution technique, 152
antipatterns and, 288
performance and, 9, 11, 17
performance improvements and, 309, 311
software, 344, 367-368
SPE and, 47, 111, 435
SPE models and, 72, 115, 121
technical, 344, 367
tuning and, 449
Architecture evaluation, 89-102, 343-345, 366-371
ARM (Application Resource Measurement), 233-236
system development kit (SDK), 234
use of, 236
ARM Working Group, 234
specifying, 139, 171
specifying units, 149
workload and, 147
ASP (Active Server Pages), 344
Assembly language, efficiency and, 397
Asynchronous callback, 66, 118, 160, 471
Asynchronous communication, 65, 117
ATM (automated teller machine)
case study, 32-39
Fast Path, 246-247, 264, 266-267
measuring resource requirements, 208
performance failure, 8
use case diagram, 50
Auer, K., 10
Average value, 152, 380
B Basic node, 73, 77, 476
Batch job, 255
Batching pattern, 272-276
average versus transient behavior, 420
Batching rule and, 325
flow balancing and, 401
receiver-side Batching, 274
sender-side Batching, 274
versus individual items, 273
Batching rule, 325
Beck, K., 10
See Performance benchmark, Measurements for SPE
Bensley, G., 315
Bentley, J., 323-326
Best- and worst-case
analysis, 41, 384
estimate, 30, 102, 197
model strategy, 164
response time, 72
Unified Process and, 436
See god Class antipattern
Booch, G., 265, 407, 433, 467
Bottleneck, 5, 151, 165, 314, 414
Brown, W. J., 288
Bulka, D., 327, 332
Busy wait, 398-400
constraint specification, 49, 473
object creation, 329
sharing strategy, 320
C++ solutions, 331-332
Caching rule, 324-325
Call processing example, 8, 294-296
Excessive Dynamic Allocation antipattern, 294
Capacity management, 423-424
Capacity planning, 20, 109, 429
modeling and, 424
SPE and, 451
CASE (Computer-Aided Software Engineering), 179
integration with SPE tools, 442-444
Case node, 75, 77, 476
Centering Principle, 245-247
Caching rule and, 325
example, Web application, 362
Fast Path speed-up and, 316
patterns and, 263, 266, 269, 272, 283
performance antipatterns and, 306
using, 257, 447
CGI (Common Gateway Interface), 344, 354
Circuitous Treasure Hunt antipattern, 250, 296-301
Adapter pattern and, 301
ICAD case study and, 297
performance gain from refactoring, 299
refactoring, potential disadvantages, 300
Class diagram, 30
Clements, P. C., 9-10, 115
Client/server application, 341
Clock, operating system, 219-220
CMG (Computer Measurement Group), 222, 424, 447
Cohen, S. S., 291-292
Collaboration diagram, 50, 52
COM (Component Object Model), 110
See Performance antipatterns
Communication, 115, 271
Communication overhead, 254
Communication protocol, 319-320
Compiler optimization, profile-based, 317
Component, stereotype, 91
Computer device usage, 85
Computer resource requirement, 176-178
example, 87, 126
example, Web application, 358
specification, 37-39, 86