1. Copyright © 2002-2004, Software Engineering Research. All rights reserved. Creating Responsive Scalable Software Systems Dr. Lloyd G. Williams Software Engineering Research 264 Ridgeview Lane Boulder, CO 80302 (303) 938-9847 boulderlgw@aol.com

2. Federal Software Spending

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

4. Software Performance Engineering

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

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

7. SPE Model-based Approach Conventional Models Software Prediction Models

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

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

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

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

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

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

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

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

16. ATM Sequence Diagram

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

18. 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.)

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

20. Example Specifications initiate session ComponentK Instr ATM Screens get & interpret request withdrawal print balance terminate session 200 150 250 400 100 1 0 1 0 2 2 0 1 1 dispense cash 3501 Disk I/O’s 1 0

21. Sequence Diagram

22. Expansion of processWithdrawal

23. Software Execution Model 

24. Software Resource Requirements

25. Computer Resource Requirements Devices Service Units Screen Host Log Delay Service Time CPUDiskDisplayDelayNet 11111 Sec.Phys. I/OScreensUnitsMsgs. 0.0011 0.00532 0.0011 1 10.02110.05

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

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

28. Results

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

30. System Performance Model

32. Distributed Applications

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

34. Partitioning the Model Estimate the Delay for System Interactions

35. Message Types SynchronousAsynchronous Deferred SynchronousAsynchronous Callback

36. EG Synchronization Nodes

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