Copyright © , Software Engineering Research. All rights reserved. Creating Responsive Scalable Software Systems Dr. Lloyd G. Williams Software Engineering Research 264 Ridgeview Lane Boulder, CO (303)

Federal Software Spending

Objectives  To provide an overview of modeling concurrent and distributed systems  To illustrate SPE models and solutions (exercise)  To discuss performance-oriented design  Principles  Patterns  Antipatterns

Software Performance Engineering

SPE  Software performance engineering (SPE) is a systematic, quantitative approach to constructing software systems that meet performance objectives.  SPE prescribes  principles for creating responsive software  the data required for evaluation  procedures for obtaining performance specifications  guidelines for conducting performance evaluation at each development stage

Performance Balance  Quantitative Assessment  Begins early, frequency matches system criticality  Often find architecture & design alternatives with lower resource requirements  Select cost-effective performance solutions early Resource Requirements Capacity

SPE Model-based Approach Conventional Models Software Prediction Models

SPE Model Requirements  Low overhead  use the simplest possible model that identifies problems  Accommodate:  incomplete definitions  imprecise performance specifications  changes and evolution  Goals:  initially distinguish between "good" and "bad"  later, increase precision of predictions  provide decision support

SPE Modeling Strategies  Simple-Model Strategy  start with the simplest possible model that identifies problems with the system architecture, design or implementation plans.  Best- and Worst-Case Strategy  use best- and worst-case estimates of resource requirements to establish bounds on expected performance and manage uncertainty in estimates  Adapt-to-Precision Strategy  match the details represented in the models to your knowledge of the software processing details

SPE Process Steps 1.Assess performance risk 2.Identify critical use cases 3.Select key performance scenarios 4.Establish performance objectives 5.Construct performance models 6.Determine software resource requirements 7.Add computer resource requirements 8.Evaluate the models 9.Verify and validate the models

What Do You Need To Know To Do SPE (And How Do You Get It)?

What Do You Need to Know Performance Objectives WorkloadSoftware/ Database Execution Environment Resource Usage Estimates

Workload Data  Pareto principle ( ‘80-20 rule’ )  More than 80% of the software requests will be for less than 20% of the functions of the system  First: scenarios of typical activity  Number of concurrent users  Request arrival rates  Performance goals  Later, add large scenarios, critical scenarios, etc.

Example: ATM System System Functions: Scenario? Get balance Checking Savings Withdrawal Checking Savings Credit card Make payment From checking From savings In envelope Deposit Savings Checking

Software Specifications  Execution paths for scenarios of interest  Objects / methods to be executed  probability of execution  number of repetitions  protocol  Database accesses  Level of detail increases as development progresses

ATM Sequence Diagram

Example (continued)  Processing scenario: Request withdrawal 1. Initiate session 2. Get and interpret request {response = withdrawal, checking acct} 3. Trans Authorize (Withdrawal) 4. Dispense cash 5. Print receipt 6. Terminate session  Performance Objective: Response time _______ secs.  Workload intensity, e.g., number of session arrivals per hr. per ATM

Environment  Platform and network characteristics:  configuration  device service rates  Software overhead, e.g., database path lengths, communication overhead, etc.  External factors, e.g., peak hours, bulk arrivals, batch windows, scheduling policies  Case study Environment Specifications:  time for ATM communication  CPU speed  system configuration (devices, service times, etc.)

Resource Usage  CPU  Work Units  or # of instructions executed  or measurements of similar software  I/O  Database calls  Communication  Other devices  Software overhead calls & characteristics Estimates + Lower / Upper Bounds Estimates + Lower / Upper Bounds

Example Specifications initiate session ComponentK Instr ATM Screens get & interpret request withdrawal print balance terminate session dispense cash 3501 Disk I/O’s 1 0

Sequence Diagram

Expansion of processWithdrawal

Software Execution Model 

Software Resource Requirements

Computer Resource Requirements Devices Service Units Screen Host Log Delay Service Time CPUDiskDisplayDelayNet Sec.Phys. I/OScreensUnitsMsgs

Software Model Solutions  Types of solutions:  Best case - shortest path in graph  Worst case - longest path in graph  Average  Variance  Approach  Repeat reduction rules on typical structures until graph contains one node with the computed solution  Apply reductions to each resource specification (t), then combine the results

Simple Reduction Rules: Average Analysis t = t 1 + t 2 + …+ t n t = nt 1 t = t 0 + p 1 t 1 + p 2 t 2

Results

System Execution Model  Characterizes performance in the presence of factors that could cause contention for resources  Multiple workloads  Multiple users  Provides additional information  Metrics that account for resource contention  Sensitivity of performance metrics to variations in workload composition  Scalability of the hardware and software  The effect of new software on service level objectives of other systems that execute on the same facility  Identification of bottleneck resources  Comparative data on options for improving performance via: workload changes, software changes, hardware upgrades, and various combinations of each

System Performance Model

Distributed Applications

Modeling Strategy  Follow Simple-Model strategy—start with software execution model  Focus on one scenario/processor at a time  Approximate delays for communication/ synchronization with other scenarios  If the software execution model shows no problems, proceed to  System execution model  Advanced system execution model

Partitioning the Model Estimate the Delay for System Interactions

Message Types SynchronousAsynchronous Deferred SynchronousAsynchronous Callback

EG Synchronization Nodes

Summary  Early modeling is important for distributed systems  Use Simple-Model strategy  SPE models are straightforward to construct and solve  Performance principles, patterns and antipatterns can guide performance-oriented design