Chapter 11: Performance Antipatternscs.queensu.ca/~elgazzar/soft437/lecture-notes/Chapter11.pdf · • Performance antipatterns illustrate how to identify a bad situation and provide

Software Performance Analysis

Chapter 11: Performance Antipatterns

SOFT 437

SOFT 437 – Chapter 11 2

Antipatterns

• Design patterns document recurring solutions to common design problems

• The use (or misuse) of design patterns produces negative consequences

• Antipatterns document common mistakes• Performance patterns illustrate “best practice”

approaches to achieving responsiveness and scalability

• Performance antipatterns illustrate how to identify a bad situation and provide a way to rectify the problem


Refactoring

• Antipatterns are refactored (restructured or reorganized) to overcome their negative consequences

• A refactoring is a correctness-preservingtransformation that improves the quality of the software

• Example:– A set of class can be refactored to improve modifiability

by moving common properties to an abstract superclass– The transformation does not alter the semantics of the

application



Origins of AntiPatterns

• A manager or developer– Does not know any better– Does not have sufficient knowledge or experience

solving a particular problem– Applied a perfectly good design pattern in the wrong

context


State of Affairs

• Five out of six software projects are considered unsuccessful

• One third of all software projects are canceled• For delivered systems the actual budget and time is

double than expected


AntiPattern Structure

• Description of the general form• Symptoms on how to recognize the general form• Causes that led to the general form• Consequences of the general form• Refactored solution on how to change the Antipattern

into a healthier situation


AntiPattern Categories

• Development AntiPatterns• Architectural AntiPatterns• Managerial AntiPatterns• AntiPatterns apply to software construction as well

as software evolution





Antipattern Template

• Name: the section title• Problem: What is the recurrent situation that causes

negative consequences?• Solution: How can we avoid, minimize or refactor

the antipattern?


Antipatterns

• “God” Class• Excessive Dynamic Allocation• Circuitous Treasure Hunt• One-Lane Bridge• Traffic Jam


God Class

• A “god” class is one that performs most of the work of the system, relegating other classes to minor, supporting roles

• A “god class” typically– Has a single, complex controller class– Surrounded by simple classes that serve only as data

containers• The data container classes typically

– Contain only accessor and mutator operations (get() and set() data)

– Perform little or no computation of their own


Example

• The Controller does all of the work– Requests information – Makes decisions– Tells the Valve what to do

• The Valve has no intelligence– Reports its status– Responds to open() and

close() invocations

void openValve(){status currentStatus;currentStatus = theValve-> getStatus();if (currentStatus != open)

theValve->open();}

ControlleropenValve()closeValve()

Valves tatus : enum

getStatus()open()c lose()


Example (con’t)Controller

openV alve()closeValve()

Valves tatus : enum

open()c lose()

void openValve(){theValve->open();

}

void open(){if (status != open)

status = open;}


Problems -- God Class

• Causes excessive message traffic– In functional form, the “god” class requests and

updates the data it needs to control the system from subordinate classes

– In the data form, the subordinate classes request and update data in the “god” class

– The number of messages required to perform a function is larger than it would be in a design that assigned related data and behavior to the same class



Solution – God Class• Refactor the design to distribute intelligence uniformly across

the top-level class in the application• Keep related data and behavior together• Beware of either:

– 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 it deals with

• The solution to the “god” class problem embodies the Locality Principle– an algorithm and the data that it requires are localized in the

same object


Performance Gain for the Refactoring

• The performance gain for the refactored solution will be

– Ts is the processing time saved– Ms is the number of messages saved– O is the overhead per message

OMT ss


Excessive Dynamic Allocation

• With dynamic allocation, objects are– Created when they are first accessed– Destroyed when they are no longer needed

• This can often be a good approach to structuring a system, providing flexibility in highly dynamic situations

• Excessive dynamic allocation addresses frequent, unnecessary creation and destruction of objects of the same class


Problem – Excessive Dynamic Allocation

• When an object is created,– The memory to contain it (and any objects that it contains) must

be allocated from the heap– Any initialization code for the object and the contained objects

must be executed• When the object is no longer needed

– Necessary clean-up must be performed– The reclaimed memory must be returned to the heap to avoid

“memory leaks”• The performance impact may be significant when a large

number of objects are frequently created and then destroyed


Example: A Call Processing

• A Call object may not seem excessive– A Call is a complex object

that contains several other objects that must also be created

• A switch can receive hundreds of thousands of offHook events each hour

• The overhead for dynamically allocating call objects adds substantial delays to the time needed to complete a call


Cost of Dynamic Allocation

• The cost of dynamic allocation, C, is

– N is the number of calls– depth is the number of contained objects– Sc and Sd are the service time to create and to destroy

the object, respectively

depth

dc SSNC )(



Solution – Excessive Dynamic Allocation

• Pre-allocate a “pool” of objects and stores them in a collection– Recycle objects rather than to create new ones each

time they are needed– Useful for systems that continually need many short-

lived objects– Eliminate the need for object creation and destruction

by “recycling” objects from a pool– This is an application of the Processing vs.

Frequency Principle


Solution – Excessive Dynamic Allocation (con’t)

• Share objects rather than create new ones– Use sharing to eliminate the need to create new

objects


Problem - Circuitous Treasure Hunt

• Software retrieves data from a first table, uses those results to search a second table, retrieves data from that table, and so on, until the “ultimate results” are obtained

• The impact on performance is the large amount of database processing required each time the “ultimate results” are needed– It is especially problematic when the data is on a

remote server, and each access requires transmitting all the intermediate queries and their results via a network


Database Example



Problem – Circuitous Treasure Hunt (con’t)

• In object oriented systems, operations have large “response sets”– One object invokes an operation in another object,

that object then invokes an operation in another object, and so on, until the “ultimate result” is achieved

– Each operation returns, one by one, to the object that made the original call

• The performance impact is the extra processing required to identify the final operation to be called and invoking it, especially in distributed systems


Database Example



Solution – Circuitous Treasure Hunt

• Select a different data organization if a database access problem occurs early in development– Put the data close to where it will be used

• Calls saved

– Cs is the total number of calls saved– aj is the number of associated objects in the level

below for each object in level j

rootpathj

js aC


Solution – Circuitous Treasure Hunt (con’t)

• For distributed systems, if you cannot change the database organization, you can reduce the number of remote database calls by using Adapter pattern to provide a more reasonable interface for remote calls– The Adapter would then make all the other (local)

database calls required to retrieve the “ultimate result”, and return only those results to the remote callers


Adapter Design Pattern

• Adapters are used to enable objects with different interfaces to communicate with each other

• Object adapters use a compositional technique to adapt one interface to another


Solution – Circuitous Treasure Hunt (con’t)

• For design with large response sets, an alternative is to create a new association that leads directly to the “ultimate result”


The One - Lane Bridge

• One-lane bridge is that – Traffic may only travel in one direction at a time– If there are multiple lanes of traffic all moving in

parallel, they must merge and proceed across the bridge one vehicle at a time

• This increases the time required to get a given number of vehicles across the bridge and can also cause long backups


Problem - The One-Lane Bridge

• One, or only a few, processes may continue to execute concurrently

• All other processes must wait• Examples:

– Locks in database ensure that only one process may update the associated portion of the database at a time

– Many processes make a synchronous call to another process that is not multi-threaded

– The database key is a date-time stamp for an entity, or any key that increases monotonically



Solution – The One-Lane Bridge

• Provide additional paths to reduce traffic on the One-Lane Bridge– Reducing the amount of time required to cross the bridge also

helps relieve congestion• For the database example, the magnitude of the

improvement depends on the intensity of new item orders and the service time for performing update. The relationship is:

RT is the residence time, S is the service time, X is the arrival rateXS

SRT

1



Solution – The One-Lane Bridge (con’t)

• The solution to the One-Lane Bridge problem embodies the Shared Resources Principle– Responsiveness improves when we minimize the

scheduling time + holding time– Holding time is minimized by reducing the service

time for the One-Lane Bridge, and by rerouting the work


Traffic Jam• The performance impact of the Traffic Jam is the

transient behavior that produces wide variability in response time

• Problems occur when– The One-Lane Bridge produces a large backlog in jobs

waiting for service, whereupon it takes a long time to return to “normal” operating conditions

– A large amount of work is scheduled within a relatively small interval

• Every user needs a report at approximately the same time• Stock market activity triggers a sudden surge in trading

activity


Solution – Traffic Jam

• If the problem is caused by the One-Lane Bridge, solving that that antipattern will reduce the effect of the Traffic Jam

• If the problem is caused by periodic high demand, seek alternatives that spread the load, or handle the demand in a different manner– Adopt the Alternative Routes pattern or the Flex Time pattern

• If the problem is caused by external factors, use SPE techniques to identify the most important workloads, and then streamline their processing as much as possible

Chapter 11: Performance Antipatternscs.queensu.ca/~elgazzar/soft437/lecture-notes/Chapter11.pdf · • Performance antipatterns illustrate how to identify a bad situation and provide

Documents