Sa 005 performance

Vakgroep Informatietechnologie – IBCN

Software Architecture

Quality Attributes & Tactics (2)

Performance

Quality Attributes Scenarios

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

Artifact

Source Environment MeasureResponseStimulus

Quality Attribute Scenarios

A Quality Attribute Scenario describes:

SOURCE: who or what STIMULUS: does something ARTIFACT: to the system or part of it ENVIRONMENT: under certain conditions RESPONSE: how the system reacts MEASURE: how you can measure this


What is Performance ?

Performance refers to responsiveness: either the time required to respond to a specific event

or the number of events processed in a given time

interval. Performance vs. Speed

Faster processors or more bandwidth do not improve timeliness; they only minimize the average response time for some services.

Example : real-time systems need predictable responsiveness.


Performance is about timing - not speed.


Real-Time Systems

Hard real-time systems: required to complete a critical task within a

guaranteed amount of time Example : avionics

Soft real-time systems: requires that critical processes receive priority

over less fortunate ones Example: on-line banking

Performance Myths ?

It is not possible to do anything about performance until you have something to measure.

Performance models are expensive and difficult to construct.


Performance Myths

It is not possible to do anything about performance until you have something to measure.

Performance models are expensive and difficult to construct.

Architecture determines performance properties.

Simple models (back of the envelope) can identify performance problems.

Annotated UML Sequence diagrams


Modeling Performance - Events

Performance requirements: Quantitative requirements defined in terms of

events and the timing constraint to respond to each event.

An event can be an interrupt, a message, a user interaction ...

Behavior Pattern: The number of event streams, the worst case and

the steady state arrival rates for each stream. An event stream is a single source of events such

as a hardware interrupt. Arrival rates can be periodic, stochastic, bursty or

sporadic


Performance Concerns (1/2)

Latency : How long does it take to respond to a specific

event. Jitter: is the variation in response time.

Throughput : How many events can be responded to over a

given interval of time ?


Performance Concerns (2/2)

Capacity : How much demand can be placed on the system

while continuing to meet latency and throughput requirements ?

It is the maximum achievable throughput without violating latency requirements.

Modes : What happens when system capacity is exceeded

and not all events can be responded to in a timely manner ?

2 common modes: reduced capacity and overload Reduced capacity : resource cease to function


Performance concerns - overview


Ref: Quality Attributes : Technical Report CMU - CMU/SEI-95-TR-021 Chapter 3 Performance p. 7 – 14 (see Download section)


Performance generic scenario (1/3)

Source The stimuli arrive either from external (possibly multiple) or internal sources. In our example, the source of the stimulus is a collection of users, a message or an interrupt.

StimulusThe stimuli are the event arrivals

Periodic events; Sporadic events; Stochastic events Bursty events

ArtifactThe artifact is the system's services or a component



EnvironmentThe system can be in various operational modes: Normal mode Overload mode Reduced Capacity mode

ResponseThe system must process the arriving events.

This may cause a change in the system environment or the service level.



Response measureThe response measures are the time it takes to process the arriving events: Latency or a deadline by which the event must be

processed Jitter: the variation in processing time Throughput the number of events that can be

processed within a particular time interval Capacity: the maximum achievable throughput without

violating latency requirements. Miss rate, data loss: a characterization of the events

that cannot be processed

Performance QAS

p. 15

Source

External

Internal

events

Environment

Normal mode

Overload mode

Reduced Capacity mode

Measure

Latency

Deadline

Throughput

Capacity

Jitter

Miss rate

Response

Change in system mode

or

service level.

Stimulus

Periodic

Sporadic

Stochastic

Bursty

events

Artifact

Case: Digital Signage – Public Transport


Performance QAS :

SOURCE who or what A bus subsystem

STIMULUS does something ... sends a msg with its speed & location every 15 secs.

ARTIFACT to the system or part of it ... to the central system

ENVIRONMENT under certain conditions ...during normal operations

RESPONSE how the system reacts The system produces an estimated arrival time for all relevant displays and sends it out

MEASURE how you can measure this ... within 30 seconds after receiveing the message from the bus.

Role of the Architect


Architect’s role: to establish the (minimum) amount

of hardware that will allow the system to meet its

performance goals.

WorkloadResource

Capacity


Performance Tactics

Tactics

to Control

PerformanceEvent

Arrives

Response generated

within Time Constraints

Response Time = S { Working , Waiting}

Resource Contention Resource Availability Computational dependencies

Resource

ConsumptionBlocked

Time CPU, storage, memory ... Designed entities: buffers,

critical sections. Processing sequence


Resource Consumption

Processing sequence of an event: Message generated by one component Placed on network and arrives at another component The event is then placed in an input-buffer The event is transformed in some fashion

e.g. CORBA marshalling The transformed event is then processed by an algorithm The result is then placed in an output-buffer Finally results are sent

Each phase contributes to the latency for the event

Resource Consumption


The bus system sends a message with speed & location every 15 seconds

to the central system. The central system produces an estimated arrival time for all relevant

displays and sends it out within 30 seconds after receiving the message from the bus.

Bus System Central System

30 secs


Blocked-Time

A computation can be blocked because: A resource is unavailable (somebody else has it) The result of another computation is unavailable

Contention for resources Single streams of events or multiple streams of events In general more streams more contention greater latency This depends on the arbitration mechanism for contention

Availability of resources Resource unavailability (as in a crash and being swapped out)

contributes to latency.

Dependency on other computation Dataflow – can’t perform operation till the data is there


Performance: (Non -) Architectural Aspects

The performance of a systems depends on both architectural and non-architecture aspects. Architectural aspects of performance:

Communication between components Partitioning of functionality Allocation of resources

Non-architectural aspects of performance: Choice of algorithms How these algorithms are coded


Performance Tactics

Resource Demand Time between events (demands) How much is consumed per request ?

Resource Management Without control on the demand side, the available

resources must be managed.

Resource Arbitration Resource contention and conflict resolution Scheduling:

Priority based Pre-emption


Resource Demand (1/2)

Increase Computational Efficiency Understand algorithms: O(n) versus O(n2) Time/Space trade-off.

Rendering versus stored image Compressed vs Uncompressed Lookup tables

Reduce Computational Overhead Eliminate Intermediaries Modifiability/Performance trade-off. Precompute results


Resource Demand(2/2)

Reduce the number of events. Manage event rate

Over engineered systems – slow down event generation

Control frequency of sampling – process events at the rate you can regardless of arrival rate Possible loss of data (events)

Bound execution times Place a limit (deadline) on how much computation will be done for an

event This could even be varied based on queue lengths etc.

Bound queue sizes


Resource Management

Concurrency Multitasking and threading. Load balancing.

Keep multiple copies of data & computations More buffers, more processes Client-server: typical TCP concurrent server replicates the server

process to deal with requests “in parallel” Replicas reduce contention: caching But add complexity:

consistency and synchronisation

Increase available resources Add processors, memory, bandwidth. Cost/performance trade-off


Resource Arbitration

All resources need to be scheduled Priority assignment Dispatching and pre-emption Applies to processor, network, buffers ….

Scheduling policies : FIFO - First Come/First Served (FCFS) Fixed-priority: a fixed priority is assigned to each request

then higher priority requests are processed first Deadline monotonic Rate monotonic (periodic)

Dynamic Priority scheduling Round robin Earliest deadline first.


Performance Tactics: Summary

Performance

Resource

Demand Resource

Management

Resource

Arbitration

Response

generated

within

Time Constraints

Event

Arrives

•Increase computational efficiency

•Reduce computational overhead

•Manage Event Rate

•Control Frequency of Sampling

•Introduce concurrency

•Maintain multiple copies

•Increase available resources

•Scheduling

Exercise : Personal Mobile Marketing

Use Case Description: An international retail chain wants to send their

customers discounts coupons for special offers. The information is send via e-mail and is pushed

to the mobile phone. The discount coupons are specific for special

offers based on the shopping profile of the customer.

The e-mail message contains a marketing text prepared by the local retail stores in native language. The corporate information about the products on offer and the customer data are retrieved from the private corporate cloud.


HTML2PDF conversion


Private Cloud :•QR code for the discount•Special offer product info•Customer profile

Local Servers:•Marketing text•PDF creation•Mail & Push

HTML2PDF Performance QAS

p. 31

Source

Internal

event

Environment

Normal mode

Measure

Latency:

< 1 sec

Jitter:

Not specified

Response

PDF file

Creation

Stimulus

HTML

To PDF

Conversion

Request

Artifact

Module:

HTML2PDF

HTML2PDF Measurements


Latency: average response time: 242 msec.

Jitter:

• Response time < 0,5 sec : 921 calls

• Response time > 2 sec : 38 calls ( 4%)

Project Example

p. 33 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

Artifact

System

Source

UserEnvironment

Normal mode

Response measure

?

Response

Item is placed in the room

Stimulus

Adds new piece of

furniture to the room

Project: Design Visualization

Technology

Sa 005 performance