Programma della seconda parte del corso

(1)

1 Ingegneria del Software II, a.a. 2004/05 V.Cortellessa ©, University of L’Aquila

Programma della

seconda parte del corso

Introduction

Reliability

Performance

Risk

New trends in software modeling:

Metamodeling, MOF/QVT, UML 2

• Software Performance Engineering

• Layered Queueing Models

• Stochastic Petri Nets

SOFTWARE PERFORMANCE

ENGINEERING

(2)

Introduction

• A systematic, quantitative approach

to cost-effectively constructing

systems that meet performance

objectives

• Focus on both process and techniques

• Modeling as part of software

lifecycle

The Holy Graal

Requirements

Design

Implementation

Execution

Maintenance

Performance

bounds,

scalability

Architecture

selection

Performance

understanding

Dynamic

optimization

Capacity planning,

static optimization

Software Model

(3)

SPE Process

performance risk

critical cases

evaluate

verify & validate models

performance scenarios

objectives

performance model

resource requirements

modify product concept

revise objectives

modify/create scenarios

feasible

infeasible

performance

acceptable

Model Lifecycle

Early design

Detailed Design

Implementation

Post-implementation

Software

Model

Resource

Requirements

System

Model

None

Rough Estimate

Rough

Detailed

Estimates

Yes

Revised &

Measured

Yes

(4)

Software Execution Graphs

• Mean, best-,worst-case

scenarios

• Static analysis

• L1, P1, P2 data dependencies

• Data dependencies typically

are functions of inputs,

example:

– L1(# of employees)

– P1(# of women)

• Level of abstraction varies

P1

P2

C1

C2

C3

C4

L1

(

2 ₄

)

3

1

2

1

1 L

t

C

P

t

C

P

t

C

t

x

T

=

+

⋅

+

⋅

+

⋅

Software Execution Graphs

DB update SendEmail

Web

Server

Business

Logic

DB

Server

Mail

Server

Web Server

ClientRequest BL.Checkout RenderPage

Business Logic

WS.Checkout BL.Checkout CalculateOrder ReplyWS

(5)

Resource Requirements

P1

P2

C1

C2

C3

C4

L1

7

4

13 Mean

8

6

15 Worst

4

3

10 Best

Network

(Nmsg)

Disk

(I/Os)

CPU

(Kinstr.)

Devices

Node C1

Evaluation Process

(

C1

)

1 (

(

C2

)

1 (

C3

)

2 (

C4

)

x

hm

v

L

hm

v

P

hm

v

P

hm

v

T

=

+

⋅

+

⋅

+

⋅

x

t

P1

P2

C1

C2

C3

C4

L1

1 C

v

Resource Usage Vector

flops, language operations,

instructions, memory

references, etc

(

v

C

1 )

hm

Hardware Model

statistical, analytical,

simulation

(6)

Software Resource Requirements

Types of resources:

– CPU usage

– SQL operations

– File I/O

– Messages

– Authentications

– Middleware calls

– Inter-process

communication

– User delays

• Work units

– Define classes of

operations

• Think about the effect

on hardware

• Multiple hardware usage

• Low # of resources in

early design, increase

latter

• Requires cooperation of

experts

Computer Resource Requirements:

Overhead Matrix

0.05

1

0.002

1 Service

Time

1 Delay

1

0.004 Msgs

1

0.005 I/O

0.01 WorkUnit

Msgs

Sec.

Phys.

I/O

Sec

Units

1

2

2 Quantity

Network

Delay

Disk

CPU

Devices

(7)

System Execution Models

• Software model does not consider resource

contention

• System execution model outputs:

– Resource contention metrics

– Sensitivity analysis to workload parameters

– Bottleneck analysis

– Interference of background loads

• Queuing Network Model (QNM)

• You better find a tool for this!

A QNM Example

return html calculate sum

check availability WorkUnits_DB

Msgs 2 0 5 WorkUnits DB Msgs 1 0 3 WorkUnits DB Msgs 2 1 6 CPU Disk Network 20 I/Os 1 msg 4211 Kins

Enter

Exit

CPU

Disk

Network

Device

Visits

Service Time

CPU

.1203

all

.0276

Disk

20 .4500

Network

1 Outputs:

throughput, utilization, residence

time, queue lengths, response times

(8)

Measurement Usage in SPE

• System understanding

– Similar system measurements to

understand target system

• Model updates

– Represent software changes in

model

• Software performance evaluation

• Model specification

– Workload data & resource usage

• Model validation & verification

Types of Measurement Data

• Workload data (e.g. frequency of

transactions)

• Data characteristics (e.g. records in DB)

• Execution characteristics

– Path characteristics (e.g. loop iterations)

– Software resource usage (e.g. DB queries)

– Processing overhead (DB queries to disk I/O)

• Computer system usage

– Scenario response time (e.g. trans. delay)

– Scenario throughput (e.g. trans. served/sec)

– Resource utilization, throughput, queue lengths

(9)

SPE·ED: Overview

• Target systems:

distributed, web-based,

client-server, mainframes

• Users:

performance engineers, software

architects

• Paradigm:

Software Performance

Engineering (SPE)

• Technology:

analytics and simulation

(CSIM)

• Recently extended to support Distributed

Object Technology (process composition,

component communication & coordination)

Performance Engineering Services

SPE·ED: Process

Software

Model

System

Model

Initial estimates

CSIM

0 10 20 30 40 50 60 70 80 90 1st Qtr2nd Qtr3rd Qtr4th Qtr

Performance

Visualization

Export to RDBMS

(10)

SPE·ED: Example SEG

(11)

Introduction

• Execution Graphs and “flat” Queueing

Models are not suited to deal with

client-server mechanisms and

layered architectures

• Layered Queuing Models

take into

account contention for software

servers and devices

Basic idea

Client

S1

P1

E1

TM=5 ST=[0,4] Z=10 V=3 TM=1 ST=[5,0] Z=0

P2

S3

S4

E1

P3

P4

TM=2 ST=[4,0] Z=0 TM=1 ST=[2,0] Z=0 V=2

S2

E1

TM=1 ST=[4,0] Z=0 PS PS PS PS V=3 V=3 V=1 S3 S4 P4 S1 S2 S4 S3 P3 P2 Client S2 P1 S1

SUBMODEL 1

SUBMODEL 2

SUBMODEL 3

(12)

LQN as extension of QN

• LQN as an extension of QN

– models both

software tasks

(rectangles) and

hardware devices

(circles)

– represents

nested services

(a

server is also a client to other

servers)

– software components have

entries

corresponding to different

services

– arcs represent

service requests

(synchronous and asynchronous)

– multi-servers

used to model

components with internal

concurrency

• LQN limitations

– Approximate solution

– Unsuited architectural models

(e.g., peer-to-peer)

clientE

service1

service2

Appl

Query1

Query2

Client

CPU

ClientT

DB

CPU

DB

CPU

Disk1

Disk2

task

entries

device

Types of LQN Requests

a) Synchronous

_Client Server [s1, s2] included services phase1 (s1)

Client

Server

synchronous message busy reply idle waiting phase2 (s2)

c) Forwarding

[t1, t2] [s1, s2] Client Server1 Server2

Server2

forwarding

Client

reply to the original client

Server1

synchronous message busy busy

phase1 (s1) phase2 (s2) idle

phase1 (t1) phase2 (t2) idle idle waiting

b) Asynchronous

_Client Server [s1, s2]

Client

Server

included services phase1 (s1) asynchronous message

(13)

LQN extensions: activities, fork/join

e2

Remote

_Client

Internet Internet Internet Internet Local Local Local Local Wks WksWks Wks Web Web Web Web Proc Proc Proc Proc Remote Remote Remote Remote Wks Wks Wks Wks SDisk SDiskSDisk SDisk eComm eCommeComm eComm Proc Proc Proc Proc DB DB DB DB Proc Proc Proc Proc Secure Secure Secure Secure Proc Proc Proc Proc

1..n

e1

Local

Client

1..m

e4

_Server

Web

e3

a4 [e4] a4 [e4] a4 [e4] a4 [e4] & a1 a1a1 a1 a2 a2 a2 a2 a3a3a3a3 &

e5

eComm

Server

e7

DB

e6

Secure

DB

Disk DiskDisk Disk

(14)

Definition

Petri Nets (PN) are a graphical paradigm for

the formal description of

the logical interactions among parts

the flow of activities in complex systems

PN are particularly suited to model:

Concurrency and Conflict

Sequencing, conditional branching and looping

Synchronization

Sharing of limited resources

Mutual exclusion

Timed model were subsequently extensively explored,

following two main lines:

Random durations : Stochastic PN (SPN)

Deterministic or interval: Timed PN (TPN)

Petri Nets

vs

Time

The original PN did not convey any notion of

time.

For performance analysis it is necessary to

introduce the duration of the events

associated to PN transitions.

(15)

Definitions

• A Petri net (PN) is a

bipartite directed

graph consisting of two kinds of nodes:

places

and

transitions

– Places typically represent conditions within the

system being modeled

– Transitions represent events occurring in the

system that may cause change in the condition

of the system

– Arcs connect places to transitions and

transitions to places (never an arc from a place

to a place or from a transition to a transition)

Example of a PN

p1 – resource idle

p2 – resource busy

t1 – task arrives

t2 – task completes

p1

t2

p2

t1

(16)

Example of a PN

p1 – resource idle

p2 – resource busy

p3 – user

t1 – task arrives

t2 – task completes

p1

t2

p2

t1

p3

Definition of PN

A PN is a 5-tuple (P,T,I,O,M)

P

set of places

T

set of transitions

I

input arcs

O

output arcs

M

marking

(17)

Arcs

• Input arcs are directed arcs drawn from places

to transitions, representing the conditions that

need to be satisfied for the event to be

activated

• Output arcs are directed arcs drawn from

transitions to places, representing the

conditions resulting from the occurrence of the

event

Places

• Input places of a transition are the

set of places that are connected to

the transition through input arcs

• Output places of a transition are

the set of places to which output

arcs exist from the transition

(18)

• Tokens are dots (or integers) associated with

places; a place containing tokens indicates that

the corresponding condition holds

• Marking of a Petri net is a vector listing the

number of tokens in each place of the net

Tokens

m

(m

₁

m

₂

… m

_P

)

;

P = # of Places

• When input places of a transition have the

required number of tokens, the transition is

enabled.

• An enabled transition may fire (event happens)

removing one token from each input place and

depositing one token in each of its output place.

(19)

Enabling & Firing of Transitions

up

t_repair

up

down

t_fail

“t_fail” fires

“t_repair” fires

A 2-processor failure/repair model

Example of PN

(20)

Concurrency (or Parallelism)

Synchronization

(21)

Limited Resources

Producer/consumer

(22)

Producer/consumer

with limited buffer

Mutual exclusion

(23)

Extensions of PN models

arc multiplicity

inhibitor arcs

priority levels

enabling functions (guards)

Arc Multiplicity

• An arc cardinality (or multiplicity) may be associated

with input and output arcs, whereby the enabling and

firing rules are changed as follows:

– Each input place must contain at least as many tokens as

the cardinality of the corresponding input arc.

– When the transition fires, it removes as many tokens from

each input place as the cardinality of the corresponding input

arc, and deposits as many tokens in each output places as

the cardinality of the corresponding output arc.

(24)

Inhibitor arcs are represented with a

circle-headed arc.

Inhibitor Arc

tk

pi

pj

The transition can fire iff the inhibitor place

does not contain tokens.

(25)

An Example: Before

or cardinality of the output arc

An Example: After

(26)

Priority levels

A priority level can be attached to each PN

transition.

The standard execution rules are modified in

the sense that, among all the transitions

enabled in a given marking, only those with

associated highest priority level are allowed

to fire.

Enabling Functions

An enabling function (or guard) is a boolean

expression composed with the PN primitives

(places, trans, tokens).

The enabling rule is modified in the sense that

beside the standard conditions, the enabling

function must evaluate to true.

tk

pi

(27)

• Petri nets are extended by associating

time

with the firing of transitions, resulting in

timed Petri nets.

• A

special case

of timed Petri nets is

stochastic Petri net (SPN)

where the firing

times are considered random variables.

Stochastic Petri Nets (SPN)

SPN: A Simple Example

.

10

01 λ

λ

.

µ

Reachability graph

CTMC

Server Failure/Repair

p1

t2

10

01 λ

λ

t1

p2

p1

p2

(28)

0

1

2 ...

SPN: Poisson Process

λ

SPN

model

PP with rate

RG =

CTMC

λ

0

1

2 ...

SPN: M/M/1 Queue

λ

µ

λ

µ

SPN model

M/M/1

RG = CTMC

λ

µ

(29)

Generalized SPN

• Sometimes when some events take extremely small

time to occur, it is useful to model them as

instantaneous activities

• SPN models were extended to allow for such

modeling by allowing some transitions, called

immediate transitions

, to have

zero

firing times

• The remaining transitions, called timed transitions,

have

exponentially distributed

firing times

• The enabling rules are modified: if both an

immediate and a timed transition are enabled in a

marking, immediate transition has higher

priority.

• If more than one immediate transition is enabled

in a marking, then the conflict is resolved by

assigning firing probabilities to the immediate

transitions.

Generalized SPN

T

t

Immediate transition t is

enabled!

t2

Transition t1 & t2 will fire

with p and (1-p).

t1

p

(30)

Measures of Reliability & Performance

Solving the model means evaluating the

(transient / steady state) probability vector

over the state space (markings).

However, the modeler wants to interact only at

the PN: the analytical procedure must be

completely transparent to the analyst.

There is a need to define the output measures

at the PN level, in term of the PN primitives.

Measures of Reliability & Performance

Output measures defined at the PN level.

Probability of a given condition on the PN

Time spent in a marking

Mean (first) passage time

Distribution of tokens in a place

Expected number of firing of a PN trans

(throughput)

(31)

Solving models with SPN

The use of SPN requires only the topology of the PN,

the firing rates of the transitions and the specification

of the output measures.

All the subsequent steps, which consist in:

generation of the reachability graph

generation of the associated Markov chain;

transient and s.s. solution of the Markov chain;

evaluation of the relevant process measures.

must be completely automated by a computer program,

thus making transparent to the user the associated

mathematics.

Example:

Multiprocessor with failure

• Number of processors:

n

• Single repair facility is shared by all

processors

• A reconfiguration is needed after a

covered fault

• A reboot is required after an

uncovered fault

(32)

Assumptions:

• The failure rate of each processor is

γ

• The repair times are exponentially

distributed with mean

1/τ

• A processor fault is covered with

probability

c

• The reconfiguration times and the

reboot times are exponentially

distributed with parameter

δ

and

β

,

respectively

GSPN Model for Multiprocessor