Designing User Interfaces Spring 1999

1
SE 767-NT Software Performance Engineering Robert
Oshana Lecture 21 For more
information, please contact NTU Tape
Orders NTU Media Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu
2
(No Transcript)
3
Performance Antipatterns

• Chapter 11

4
Where we are

• Introduction
• SPE Quick View
• SPE and the UML
• Software Execution Models
• Web applications and other distributed systems
• System execution models
• SPE data collection
• Software measurement and instrumentation
• Performance oriented design
• Performance patterns
• Performance anti-patterns
• Implementation solutions
• Web applications
• Embedded and real-time systems
• The SPE process
• Implementing SPE

5
Overview

• Antipatterns are conceptually similar to patterns
• Document recurring solutions to common design
  problems
• Their use or misuse produces negative
  consequences
• Document common mistakes

6
Overview

• May be more useful than patterns
• Antipatterns are refactored to overcome their
  negative consequences

7
god class

• One that performs most of the work of the system
• Relegates other classes to minor supporting roles
• A single complex controller
• Other classes are primarily container classes

8
(No Transcript)
9
Controller code snippet
10
Refactored solution
11
Refactored Controller code snippet
12
More on the God class

• A result of poorly distributed system
  intelligence
• May creep into design in several ways
• Creates problems by causing excessive message
  traffic

13
(No Transcript)
14
Things to watch for

• An object that must request lots of data from
  other objects and then update their states with
  the results
• A group of objects that must access a common
  object to get and update the data that it deals
  with
• Performance gain Ts Ms X O
• (Ts is processing time saved, M messages
  saved, O overhead/message

15
Excessive Dynamic Allocation

• Dynamic allocation create objects when first
  accessed and destroy when no longer needed
• But this is expensive
• Performance impact if this is done often

16
(No Transcript)
17
Cost of dynamic allocation

• N calls
• depth contained objects that must be created
  when the class is created
• sc, sd service time to create and destroy

18
(No Transcript)
19
Two possible solutions

• Eliminate the need for object creation and
  destruction by recycling objects from a pool
• Use sharing to eliminate the need to create new
  objects
• Flyweight pattern

20
Circuitous treasure hunt

• Typically found in DB applications
• Retrieve data from one table to search a second
  table, etc
• Large amount of DB processing required
• Remote server access even worse

21
(No Transcript)
22
(No Transcript)
23
Circuitous treasure hunt

• Also found in OO systems that have large
  response sets
• Look for option of selecting a different data
  organization
• Select a data organization that puts the data
  close to where it will be used

24
(No Transcript)
25
One lane bridge

• Traffic that may only travel in one direction at
  a time
• A point in execution where one or only a few,
  processes may continue to execute concurrently
• All others must wait
• Occurs in DB applications mainly

26
(No Transcript)
27
One lane bridge

• Provide additional paths
• Use an algorithm for assigning new DB keys
• Use multiple tables that may be consolidated
  later
• Preloading
• RT S / (1 XS)

28
(No Transcript)
29
Traffic jam

• Transient behavior that produces wide variability
  in response time
• Cause of problem seldom visible
• Sometimes related to One Way Bridge (solve by
  reducing effect)
• If caused by periodic high demand, seek
  alternatives that spread the load

30
Traffic jam

• Know the limits of scalability of the system
  before you build it, and plan for handling
  overload situations smoothly

31
(No Transcript)
32
Implementation solutions

• Chapter 12

33
Where we are

• Introduction
• SPE Quick View
• SPE and the UML
• Software Execution Models
• Web applications and other distributed systems
• System execution models
• SPE data collection
• Software measurement and instrumentation
• Performance oriented design
• Performance patterns
• Performance anti-patterns
• Implementation solutions
• Web applications
• Embedded and real-time systems
• The SPE process
• Implementing SPE

34
Overview

• Early lifecycle activities are required
• Having a good architecture and design, however,
  does not guarantee that you will meet your
  performance objectives
• Various reasons to tune application
• Initially developed without SPE
• Choices for data structures or other
  implementation alternatives not optimal
• Language has some hidden features
• Must meet new unanticipated performance

35
Performance tuning

• Process of transforming code that fails to meet
  performance objectives into better performing
  code that performs an equivalent function
• Usually conducted late in lifecycle
• Must focus on areas of biggest payoff

36
Performance tuning process

• 1. Prepare test plans that identify measurements
  to be taken and objectives
• Identify performance problems
• Identify important workloads
• Characterize properties of workloads
• Define data required
• Identify measurement tools needed

37
(No Transcript)
38
SE 767-NT Software Performance Engineering Robert
Oshana End of lecture For
more information, please contact NTU Tape
Orders NTU Media Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu