Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software (Object Technology Series) / Edition 1

Hardcover (Print)
Buy New
Buy New from BN.com
$33.86
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Hardcover)
  • All (11) from $1.99   
  • New (4) from $43.82   
  • Used (7) from $1.99   

Overview

"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:

  • Reactive versus proactive performance management
  • Using UML for SPE
  • Specifying key performance scenarios and performance objectives
  • Gathering performance data and estimating resource requirements
  • Constructing and solving performance models
  • Modeling complex interactions in distributed systems
  • Planning and conducting performance measurements
  • Principles for performance-oriented design
  • Patterns that illustrate "best practice" approaches to achieving responsiveness and scalability
  • Antipatterns that illustrate what not to do and how to fix a problem when you find it
  • SPE activities for mid- to late life cycle
  • Performance tuning strategies
  • Integrating SPE into your software process
  • SPE implementation strategies and critical success factors

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.

0201722291B07162001

Read More Show Less

Product Details

  • ISBN-13: 9780201722291
  • Publisher: Addison-Wesley
  • Publication date: 9/17/2001
  • Series: Addison-Wesley Object Technology Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 544
  • Sales rank: 896,212
  • Product dimensions: 7.30 (w) x 8.90 (h) x 1.20 (d)

Meet the Author

Connie U. Smith, Ph.D., is a principal consultant of the Performance Engineering Services Division of L&S Computer Technology, Inc. She is internationally recognized for her work in defining the field of software performance engineering and integrating SPE into the development of new software systems. She is the author of Performance Engineering of Software Systems (Addison-Wesley, 1990) and received the Computer Measurement Group's AA Michelson Award for technical excellence and professional contributions for her SPE work.

Lloyd G. Williams, Ph.D., is a principal consultant at Software Engineering Research, where he specializes in the development and evaluation of software architectures to meet quality objectives, including performance, reliability, modifiability, and reusability. His experience includes work on systems in fields such as process control, avionics, telecommunications, electronic funds transfer, Web-based systems, software development tools and environments, and medical instrumentation. He has presented professional development seminars and consulted on software development for more than 100 organizations worldwide.

0201722291AB07162001

Read More Show Less

Read an Excerpt

Chapter 1: Introduction

Knowledge of what is possible is the beginning of happiness.
—George Santayana

In This Chapter:

  • Performance failures and their consequences
  • Managing performance
  • Performance successes
  • What is software performance engineering?
  • SPE models and modeling strategies

1.1 Software and Performance

This book is about developing software systems that meet performance objectives. Performance is an indicator of how well a software system or component meets its requirements for timeliness. Timeliness is measured in terms of response time or throughput. The response time is the time required to respond to a request. It may be the time required for a single transaction, or the end-to-end time for a user task. For example, we may require that an online system provide a result within one-half second after the user presses the "enter" key. For embedded systems, it is the time required to respond to events, or the number of events processed in a time interval. The throughput of a system is the number of requests that can be processed in some specified time interval. For example, a telephony switch may be required to process 100,000 calls per hour.
Performance is the degree to which a software system or component meets its objectives for timeliness.

Thus, 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.


Note: Other definitions of performance include additional characteristics such as footprint or memory usage. In this book, however, we are concerned primarily with issues of timeliness.

There are two important dimensions to software performance timeliness: responsiveness and scalability.

1.1.1 Responsiveness

Responsiveness is the ability of a system to meet its objectives for response time or throughput. In end-user systems, responsiveness is typically defined from a user perspective. For example, responsiveness might refer to the amount of time it takes to complete a user task, or the number of transactions that can be processed in a given amount of time. In real-time systems, responsiveness is a measure of how fast the system responds to an event, or the number of events that can be processed in a given time.

In end-user applications, responsiveness has both an objective and a subjective component. For example, we may require that the end-to-end time for a withdrawal transaction at an ATM be one minute. However, that minute may feel very different to different users. For a user in Santa Fe in the summer, it may seem quite reasonable. To a user in Minneapolis in January, a minute may seem excessively long. Both objective and user-perceived (subjective) responsiveness must be addressed when performance objectives are specified. For example, you can improve the perceived responsiveness of a Web application by presenting user-writable fields first. Then, build the rest of the page (e.g., the fancy graphics) while the user is filling in those fields.

Responsiveness is the ability of a meet response time or throughput.

1.1.2 Scalability

Scalability is the ability of a system to continue to meet its response time or throughput objectives as the demand for the software functions increases. The graph in Figure 1-1 illustrates how increasing use of a system affects its response time.

In Figure 1-1, we've plotted response time against the load on the system, as measured by the number of requests per unit time. As you can see from the curve, as long as you are below a certain threshold, increasing the load does not have a great effect on response time. In this region, the response time increases linearly with the load. At some point, however, a small increase in load begins to have a great effect on response time. In this region (at the right of the curve), the response time increases exponentially with the load. This change from a linear to an exponential increase in response time is usually due to some resource in the system (e.g., the CPU, a disk, the network, sockets, or threads) nearing one hundred percent utilization. This resource is known as the "bottleneck" resource. The region where the curve changes from linear to exponential is known as the "knee" because of its resemblance to a bent knee.

Scalability is the ability of a system to continue to meet its response time or throughput objectives as the demand for the software functions increases.

Scalability is an increasingly important aspect of today's software sys-tems. Web applications are a case in point. It is important to maintain the responsiveness of a Web application as more and more users con-verge on a site. In today's competitive environment, users will go else-where rather than endure slow response times.

In order to build scalability into your system, you must know where the "knee" of the scalability curve falls for your hardware/software environ-ment. If the "knee" occurs before your target load requirements, you must either reduce the utilization of the bottleneck resource by stream-lining the processing, or add additional hardware (e.g., a faster CPU or an extra disk) to remove the bottleneck.

This book presents an integrated set of solutions that you can use to build responsiveness and scalability into your software systems. These solutions include a combination of modeling, measurement, and other techniques, as well as a systematic process for applying them. They also include principles, patterns, and antipatterns that help you design responsiveness and scalability into your software. These techniques focus primarily on early life cycle phases to maximize your ability to economi-cally build performance into your software. However, we also present solutions for systems that already exhibit performance problems.

1.2 The Importance of Performance

It's fair to ask at the outset: "Why is performance important?" The fol-lowing anecdotes illustrate the answer:
NASA was forced to delay the launch of a satellite for at least eight months. The satellite and the Flight Operations Segment (FOS) software running it are a key component of the multibillion-dollar Earth Science Enterprise, an international research effort to study the interdependence of the Earth's ecosystems. The delay was caused because the FOS software had unacceptable response times for developing satellite schedules, and poor performance in analyzing satellite status and telemetry data. There were also problems with the implementation of a control language used to automate operations. The cost of this rework and the resulting delay has not yet been determined. Nevertheless it is clearly significant, and the high visibility and bad press is potentially damaging to the overall mission. Members of Congress also questioned NASA's ability to manage the program. [Harreld 1998a], [Harreld 1998b]...
Read More Show Less

Table of Contents

Foreword by Grady Booch.

Foreword by Paul Clements.

Preface.

I. INTRODUCTION AND OVERVIEW.

1. Introduction.

Software and Performance.

Responsiveness.

Scalability.

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 Models.

SPE for Object-Oriented Systems.

What Does It Cost?

What Do You Need?

Summary.

2: SPE Quick View.

SPE Process for Object-Oriented Systems.

Case Study.

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.

Performance Solutions.

Performance Principles.

Performance Patterns.

Performance Antipatterns.

Implementation Solutions.

Summary.

3: SPE and the UML.

Overview.

Extending the UML.

Stereotypes.

Tagged Values.

Constraints.

Use Cases and Scenarios.

Use Cases.

Scenarios.

Extensions to Sequence Diagram Notation.

Instance Decomposition.

Looping, Alternation, and References.

Specifying Time.

Timing Marks.

Time Expressions.

Timing Constraints.

Time in Sequence Diagrams.

Concurrency.

Threads and Processes.

Coregions.

Parallel Composition.

Synchronization.

Summary.

II. SPE MODELS.

4: Software Execution Models.

Purpose.

Representing Software Execution Models.

Execution Graphs.

Execution Graph Restrictions.

Model Solutions.

Basic Solution Algorithms.

More Advanced Solution Techniques.

Analysis Procedures.

Execution Graphs from Sequence Diagrams.

ICAD Case Study.

Architecture 1.

Architecture 2.

Analysis of Results.

Architecture 3.

Modeling Hints.

Summary.

5: Web Applications and Other Distributed Systems.

Introduction.

Web Applications.

Distributed Object Technology.

Middleware.

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.

Database Scenario.

Order Process Scenario.

Example Summary.

Modeling Hints.

Summary.

6: System Execution Models.

Introduction.

System Model Basics.

Performance Metrics.

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.

Schedulability.

Distributed System Case Study.

Synchronization Model.

Modeling Hints.

Summary.

III. DATA COLLECTION.

7: SPE Data Collection.

Introduction.

SPE Data Requirements.

Key Performance Scenarios.

Performance Objectives.

Execution Environment.

Software Resource Requirements.

Computer Resource Requirements.

Data Gathering Issues.

Performance Walkthrough.

Topics.

When to Conduct Performance Walkthroughs.

Example.

Tips for a Successful Performance Walkthrough.

Resource Estimation Techniques.

Use Measurements.

Study Measurements.

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.

Introduction.

What Should You Measure?

Workload Data and Data Characteristics.

Path Characteristics.

Software Resources and Processing Overhead.

Computer Resource Usage.

Planning for Performance Measurement.

Key Considerations.

Performance Benchmarks.

Designing and Conducting Measurement Studies.

Performance Measurement Concepts.

Terminology.

Factors That May Affect Measurements.

Data Collection Techniques and Tools.

Data Collection Techniques.

Measuring SPE Data.

Instrumentation.

Instrumentation Design Considerations.

Implementation Alternatives.

Data Reporting.

Application Resource Measurement.

Summary.

IV. PERFORMANCE SOLUTIONS.

9: Performance-Oriented Design.

Principles for Performance-Oriented Design.

Performance Control Principles.

Performance Objectives Principle.

Instrumenting Principle.

Independent Principles.

Centering Principle.

Fixing-Point Principle.

Locality Principle.

Processing Versus Frequency Principle.

Synergistic Principles.

Shared Resources Principle.

Parallel Processing Principle.

Spread-the-Load Principle.

Using the Principles.

Summary.

10: Performance Patterns.

Overview.

Fast Path.

Problem.

Solution.

Benefits.

Consequences.

First Things First.

Problem.

Solution.

Benefits.

Consequences.

Coupling.

Problem.

Solution.

Benefits.

Consequences.

Batching.

Problem.

Solution.

Benefits.

Consequences.

Alternate Routes.

Problem.

Solution.

Benefits.

Consequences.

Flex Time.

Problem.

Solution.

Benefits.

Consequences.

Slender Cyclic Functions.

Problem.

Solution.

Benefits.

Consequences.

Summary.

11: Performance Antipatterns.

Overview.

The “god” Class.

Problem.

Solution.

Excessive Dynamic Allocation.

Problem.

Solution.

Circuitous Treasure Hunt.

Problem.

Solution.

The One-Lane Bridge.

Problem.

Solution.

Traffic Jam.

Problem.

Solution.

Summary.

12: Implementation Solutions.

Overview.

Performance Tuning.

General Performance Solutions.

Fast Path Speed-Up.

Improving Scalability.

Algorithm and Data Structure Choices.

Time Versus Space Trade-Offs.

Hardware/Software Platform Dependencies.

Performance Solutions for Object-Oriented Software.

Language-Independent Solutions.

C++ Solutions.

Java Solutions.

Summary.

V. APPLICATIONS.

13: Web Applications.

Introduction.

Performance Issues.

SPE Models for Web Applications.

Case Study: Nachtfliegen.com.

Plan Itinerary Scenario.

Software Model.

Hardware/Software Environment.

Resource Requirements.

Software Model Solution.

Performance Improvements.

System Execution Model.

Sensitivity and Scalability Analysis.

Typical Performance Problems.

Summary.

14: Embedded Real-Time Systems.

Introduction.

Embedded Real-Time Systems Background.

Timing Requirements.

Hardware Constraints.

Real-Time Operating Systems.

Distributed Systems.

Database.

Performance Issues.

Response Time and Throughput.

Schedulability.

SPE Models for Embedded Real-Time Systems.

Case Study: Telephony Switching.

Overview.

Architecture and Design.

Typical Performance Problems.

Summary.

VI. MAKING SPE HAPPEN.

15: The SPE Process.

Introduction.

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.

Performance Testing.

Baseline Models.

Post-Deployment Performance Management.

Evolutionary Changes.

Capacity Management.

SPE Artifacts.

Performance Management Plans.

Performance V&V Plan.

SPE Configuration Management Plan.

Performance Drivers.

Performance Scenarios.

Performance Objectives.

Execution Environment Specifications.

Performance Models.

Model Results.

Performance Instrumentation.

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.

Introduction.

Tools.

Modeling Tools.

Development Tools.

SPE Adoption and Use.

Experience.

Key Considerations.

Pilot Projects.

Critical Success Factors for Adoption and Use.

SPE Implementation Strategies.

Organizational Issues.

Who Pays for SPE?

Costs.

Risks.

Critical Factors for Successful Projects.

SPE Future.

Summary.

VII. APPENDIXES.

Appendix A: UML Notation.

Use Case Diagrams.

Sequence Diagrams.

Basic Sequence Diagrams.

Augmented Sequence Diagrams.

Deployment Diagrams.

Stereotypes, Tagged Values, and Constraints.

Stereotypes.

Tagged Values.

Constraints.

Appendix B: SPE Modeling Notations.

Execution Graph Notation.

Basic Nodes.

Synchronization Nodes.

Information Processing Graph Notation.

Bibliography.

Index. 0201722291T09102001

Read More Show Less

Preface

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 perfSolutions@perfeng.com. 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

Read More Show Less

Foreword

I

A multitude of pressures weigh upon the members of the software development team. First and foremost, there are the demands of functionality, cost, schedule, and compatibility with legacy systems. Technology "churn" and the need for resilience, especially in the presence of continuous change found in most Web-centric systems, add to the pile. Security, fail-safe/fault tolerance, and reliability/availability all play a role, depending on the domain. Finally (these are often considered last, unfortunately), there are the pressures of capacity, responsiveness, scalability, and, ultimately, performance.

Even if your team crafts the most perfectly functional system under budget and under schedule, you have failed if it doesn't perform in the manner that its users require. Although conventional wisdom may suggest that responsiveness and scalability are things that can always be added later, Connie and Lloyd point out that's just not so: Performance is an intrinsic element of building a system. You can't simply tack on quality to an ugly system, just as you can't apply a quick fix to make an underperforming system better--the causes are generally deep, and they're rooted in the system's architecture.

I think a better title for the book you hold in your hands would have been Everything You Wanted to Know About Performance But Didn't Have the Time or Resources to Ask.1 Connie and Lloyd have written a delightfully approachable and pragmatic book on the practice and problems of performance. Not only is this book eminently readable, but it also covers every aspect of building responsible and scalable software, from architectural issues to modeling, metrics, and process.

Connie and Lloyd speak from deep experience in this field, and they share that experience in this book. I learned a number of things from them, and I'm sure you will as well.

Grady Booch
Chief Scientist, Rational Software
April 2001

II

Software performance engineering has for decades been an art practiced by wizards. And for good reasons: It's tricky stuff. Until now most treatments of the subject were hopelessly bogged down in the details of queueing theory, Markov analysis, and esoteric scheduling algorithms. The field resembled, more than anything else, an old seafarer's chart with one big corner labeled "Here there be monsters." Only the brave of heart ventured forth, and an organization's performance engineers--in the unlikely case it even had performance engineers--were self-trained and underutilized; their potential contributions were poorly understood; and they tended to eat by themselves in the cafeteria, mumbling something sounding suspiciously like a Fibonacci sequence.

No more. As our field has matured, forces have come into play to banish the monsters.

First, the need is clear. All safety-critical software--and there's a staggering amount of that these days--is performance-critical. No one would dream of fielding a system on which the health and safety of humans or the environment depended without first making certain it would meet its performance constraints. Ask the people who build antilock braking systems, medical X-ray controllers, or avionics software if performance matters. They'll tell you it's the only thing that matters. But we are also coming to the obvious realization, if belatedly, that all software has performance constraints. If you don't believe this, revisit the issue the next time your workstation's operating system decides to show you the little hourglass symbol for no apparent reason, and you're tapping the mouse button, waiting to open a file and counting to ten under your breath. If you make it to ten, or eight, or even two, you're the victim of a performance problem.

Second, the performance engineering field itself is growing up and establishing a body of best practices that non-experts can emulate with repeatable success. Connie Smith and Lloyd Williams have been at the vanguard of this maturation movement, and they have established them-selves as world-renowned experts on not just performance engineering theory, but also on performance engineering practice. If you believe that those who can, do, and those who can't, teach, then you don't know Connie and Lloyd. They can, they do, and, lucky for us, they teach. Their combined decades of experience in helping organizations avoid (or climb out of) performance engineering pits serve as the foundation on which they have been able to make performance engineering live up to its name. The techniques are easy to grasp and can be used right away.

And third, in concert with the emerging discipline of software architecture, we are learning the importance of understanding all we can about systems before they are built and all of the bad decisions are cast into code where they are prohibitively expensive to correct.

In short, the "supply" of performance engineering is finally (thanks in no small measure to the authors) meeting the new-found "demand" for it from real organizations building real systems and facing real challenges.

So the time was right for a book, but that only tells half the story. This isn't just any book. As I read through it, I was impressed (and grateful) that Connie and Lloyd never forgot whom they were writing for. Every page is full of guidance that speaks directly to the practitioner. Useful (as opposed to merely entertaining) books tend to be read once, but referenced dozens or hundreds of times, and it is a prudent author who recognizes that. These authors were thoughtful about adopting stylistic conventions that make using the book easier to use and more productive. Where information is used, the location of its defining text is cited for a quick look-up to refresh the reader's memory. Examples are clearly identified separately from the main exposition. Important principles are boldly presented. Notes and asides that amplify the information are generously sprinkled throughout, but they are visually distinguished so as not to interrupt the main flow. Some technical books make you feel like an apprentice sky diver whose instructor just nonchalantly ordered you to "Jump!" Not this one. They're with you every step of the way.

The result is a book that 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.

Paul Clements
Software Engineering Institute
May 2001
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)