Performance Engineering Overview 1

1
Performance EngineeringOverview 1
CS 4803 EPR
Enterprise Computing Performance
2
Performance Engineering

• Performance Engineering overlaps many aspects
  of the SDLC and IT Operations

3
Performance Engineering Integration Points

• Early Integration
• Begins at requirements definition
• Develop use cases and s/w execution models
• UML-based tools can model predictive performance
• White box predictive performance simulation
• Late Integration
• Design is complete
• Code construction is usually complete or in
  progress
• Often no performance requirements exist
• Protocol simulation tools drive load
• Analyze, tune and iterate

4
Performance Validation OverviewEarly
Integration

• Access Performance Risks
• 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 (VV) the Models

5
Performance Validation OverviewEarly
Integration

• Performance Myth 1
• This myth is based on the assumption that you
  need something to measure before you can begin to
  manage performance
• Performance Myth
• It is not possible to do anything about
  performance until you have something executing to
  measure.
• Performance Reality
• The reality is that you don't need to wait to
  address performance until you have some running
  code to measure. Performance models can predict
  performance during the architectural and early
  design phases of the project. Performance
  estimation and uncertainty-management techniques
  can compensate for the lack of precise
  measurements. The models are sufficient to allow
  evaluation of architectural or design
  alternatives. It is not necessary to "guess" the
  location of bottlenecks or to wait until
  measurements are available to begin the modeling.

6
Performance Validation OverviewLate Integration

• Gather and study available documentation
• Technical architecture docs
• Functional test plans
• All requirement docs, functional and
  non-functional
• SLA docs project plans
• Project business presentations
• Interview key resources
• Architect
• Development leads
• Test leads
• Development and QA manager(s)
• Project manager
• Business analyst(s)
• DBA(s)
• Network and Infrastructure engineers
• Production operations engineers

7
Performance Validation Overview

• Document project scope
• Review project scope for approval by PM and other
  stakeholders
• Develop performance project plan
• List all tasks, dependencies, resources,
  milestones and durations
• Review project plan for approval by PM
• Develop performance plan
• Review performance plan for approval by
  stakeholders
• Develop performance models, simulation and test
  environments, per plan
• Execute models per plan
• Analyze results
• Develop report
• Present analysis

8
Reactive Performance Management

• Whats wrong with
• "Let's just build it and see what it can do."
• "We'll tune it later we don't have time to worry
  about performance now."
• "We can't do anything about performance until we
  have something running to measure."
• "Don't worry. Our software vendor is sure their
  product will meet our performance goals."
• "Performance? That's what version 2 is for."
• "We'll just buy a bigger processor."
• "Problems? We don't have performance problems."

9
Proactive Performance Management

• A better approach
• The project has a performance engineer
  responsible for tracking and communicating
  performance issues.
• Everyone on the project knows the name of the
  performance engineer.
• There is a process for identifying performance
  jeopardy (a danger of not meeting performance
  objectives) and responding to it.
• Team members are trained in performance
  processes.
• The project has an appropriate performance risk
  management plan based on shortfall costs and
  performance engineering activity costs.

10
Modeling

• Predictive modeling
• 90 Theory 10 Practice
• Practice found in more mature development shops
• Must start with software design!
• Use of Queuing models to solve Performance
  Metrics
• Complex resource requirement assumptions
• Performance models and software design should be
  UML-based
• Simulation/Evaluation tools
• 10 Theory 90 Practice
• Very few assumptions
• Laboratory testing ? concrete analysis ?
  quantifiable findings
• Very expensive
• Increasingly becoming expected/required
  pre-production practice

11
Modeling

• The Best- and Worst-Case Strategy
• The models rely upon estimates of resource
  requirements for the software execution. The
  precision of the model results depends on the
  quality of these estimates. Early in the software
  process, however, your knowledge of the details
  of the software is sketchy, and it is difficult
  to precisely estimate resource requirements.
  Because of this, SPE uses adaptive strategies,
  such as the best- and worst-case strategy.

12
Smith Chapter 1

• Response Time what is that?
• Time required to respond to a request
• Can include time required to fully service a
  request
• Front end or back end?
• Throughput what is that?
• Number of events processed in a given time period
• Scalability what is that?
• Whats another term for the curve and how do you
  find it?
• What are some of Case Studies used to illustrate
  the Importance of Performance?
• Performance Myths (Pg 10-11) what are they?

13
Smith Chapter 1

• Is SPE a Silver Bullet?
• Why?
• Why not?