1. Software Architecture
Quality Attributes & Tactics (2)
Performance
Vakgroep Informatietechnologie – IBCN

2. Quality Attributes Scenarios
Artifact
Source Stimulus Environment Response Measure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

3. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3

4. What is Performance ?
Performance is about timing - not speed.
 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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4

5. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5

6. Performance Myths ?
 Itis not possible to do anything about
performance until you have something to
measure.
 Performance models are expensive and
difficult to construct.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

7. Performance Myths
 Itis 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7

8. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

9. 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 ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9

10. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10

11. Performance concerns - overview
Ref: Quality Attributes : Technical Report CMU - CMU/SEI-95-TR-021 Chapter 3 Performance p. 7 – 14 (see Download section)
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11

12. 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.
 Stimulus
The stimuli are the event arrivals
Periodicevents;
Sporadic events;
Stochastic events
Bursty events
 Artifact
The artifact is the system's services or a component
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12

13. Performance generic scenario (2/3)
 Environment
The system can be in various operational modes:
 Normal mode
 Overload mode
 Reduced Capacity mode
 Response
The system must process the arriving events.
This may cause a change in the system environment or the
service level.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13

14. Performance generic scenario (3/3)
 Response measure
The 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14

15. Performance QAS
Artifact
Source Stimulus Environment Response Measure
External Periodic Normal mode Change in Latency
Internal Sporadic Overload mode system Deadline
Reduced mode Throughput
events Stochastic
Capacity mode or Capacity
Bursty service Jitter
events level.
Miss rate
p. 15

16. 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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16

17. Role of the Architect
Resource
Workload Capacity
Architect’s role: to establish the (minimum) amount
of hardware that will allow the system to meet its
performance goals.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17

18. Performance Tactics
Tactics
to Control Response generated
Event
Arrives Performance within Time Constraints
Response Time = S { Working , Waiting}
Resource Blocked
Consumption
Time
 CPU, storage, memory ...  Resource Contention
 Designed entities: buffers,  Resource Availability
critical sections.  Computational dependencies
 Processing sequence
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18

19. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19

20. Resource Consumption
Bus System Central System
30 secs
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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20

21. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21

22. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22

23. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23

24. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24

25. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25

26. 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26

27. 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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27

28. Performance Tactics: Summary
Performance
Resource Resource
Demand Resource Arbitration
Event •Increase
Management •Scheduling
Response
computational
Arrives efficiency
•Introduce generated
•Reduce concurrency
computational within
•Maintain
overhead
multiple copies Time Constraints
•Manage
•Increase
Event Rate
available
•Control resources
Frequency of
Sampling
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28

29. 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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29

30. HTML2PDF conversion
Private Cloud :
•QR code for the discount
•Special offer product info
•Customer profile
Local Servers:
•Marketing text
•PDF creation
•Mail & Push
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30

31. HTML2PDF Performance QAS
Artifact
Module:
HTML2PDF
Source Stimulus Environment Response Measure
Internal HTML Normal mode PDF file Latency:
event To PDF Creation < 1 sec
Conversion Jitter:
Not specified
Request
p. 31

32. HTML2PDF Measurements
Latency: average response time: 242 msec.
Jitter:
• Response time < 0,5 sec : 921 calls
• Response time > 2 sec : 38 calls ( 4%)
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32

33. Project Example
Project: Design Visualization
Artifact
System
Source Stimulus Environment Response Response
User Adds new Normal mode Item is measure
piece of placed in ?
furniture to the room
the room
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33