Model Driven Performance Analysis

University College London

James Skene – j.skene@cs.ucl.ac.uk

Outline

• Requirements for the analysis method, as I see them.

• Overview of the model driven performance approach chosen– Rationale related to the requirements.

• Future work

Performance Analysis Functional Requirements

• Assuming the existence of the TAPAS platform…• Reason about compositionality of service level

agreements• Predict application capacity

– Over-provisioning or under provisioning w.r.t SLAs a cost.

– Targeted at ASP technologies

• Enable design time performance prediction– Select architecture

Non-functional requirements

• Be usable:– Performance analysis outside usual software

engineering competence• Must be integrated with standard software

engineering practice

– Minimise cost of performance analysis.

• Be used:– Performance analysis is currently not

performed despite benefits

Approach

• Mappings from analysis to design models within the Model Driven Architecture (MDA)

• Qualitatively:– Includes UML so is integrated with standard software

engineering practice.

– Is tool supported, so:• Can integrate the technique

• Can provide assistance with the technique

• Can automate the technique

• Also meets the functional requirements!

The Model Driven Architecture (MDA)

• Family of specifications– UML – The Unified Modelling Language– MOF – The Meta-Object Facility– CWM – The Common Warehouse Meta-model– Also: CORBA – The Common Object-Request

Broker Architecture

• Not really an architecture• Software designs captured as UML models

PIMs and PSMs

• Problem: Technical infrastructure changes independently of business rules, but these are strongly coupled in designs.

• Solution: Decouple them

Platform Independent Model (PIM)

Platform Specific Model (PSM)

«realize»

Semantic domains

• PIMs and PSMs relate to different types of thing.

• It is convenient to describe these designs using different languages.– E.g. EJB implementation details

• UML can describe object oriented designs.• UML contains extension mechanisms to

provide additional interpretations for model elements.

Metamodels

UML

PIM PSM

Virtual Metamodel

Profile

Meta-model:

Model:

Profiles

• The lightweight extension mechanisms:– Stereotypes extend the meaning of UML model

elements.

– Tagged values associate qualities with model elements.

– Constraints govern the form of models, enforcing domain semantics. Act at meta-model level.

– Profiles group stereotypes, tagged values and constraints.

• Freedom through constraint• Opportunity for standardisation

Mappings

PIM

PSM PSM

Source Code

Analysis

Results

PIM

How are mappings described?

• Imperative mappings specify an algorithm

• Declarative mappings specify pair-wise constraints

• Declarative mappings can be captured in a profile using constraints.

«profile»Mapping

«profile»Design

«profile»QN

Benefits of mappings

• They can be checked, providing assistance to modellers• Declarative mappings only need to be partially

specified– The flexibility addresses the difficulty in producing feasible

analysis models.

• The mappings define a semantics for the design domain, in terms of the analysis domain concepts.

• The declarative mappings provide guidance for subsequent automated mappings.

• Can capture expert modelling techniques

Design domain: A soft-real-time profile

Based on the ‘UML Profile for Schedulability, Performance, and Time Specification’

• Stereotypes to:– Identify workload classes– Identify resources accessed under mutual

exclusion– Identify actions having resource demands

A Soft-real-time profile 2

• Tagged values to:– Specify workload parameters (e.g. population, think-

time, or arrival rate)

– Specify resource demands for actions/procedures

– Specify probabilities for choices, average number of iterations.

• Constraints:– Object containing action with resource demand must be

deployed in context where resource is available.

Example design model - sequence

:UpdateBean :ManagerBean :EmployeeBean

1:update()

2:ejbCreate()

3:ejbCreate()

{repetitions = 100, demand={cpu:10000}}

{p= 0.5, demand={cpu:100, disk1:5}}

{demand={cpu:100, disk1:5}}

Platform

Example design model – deployment

:UpdateBean

:ManagerBean

:EmployeeBean{serviceRate=0.1s}

«resource»

CPU

«resource»

Disk2

«resource»

Disk1«deploys»

«deploys»

«deploys»

{serviceRate=0.1s}

{serviceRate=0.001s}

A performance analysis domain profile

• Queuing networks• Stereotypes:

– Identify instances as queues, delays or populations.

• Tagged values:– Specify service intervals and probabilities on links.

• Constraints:– Ensure that the network is connected.

Example QN Collaboration

«client»

Workload

«queue»

CPU

«queue»

Disk1

«queue»

Disk2{thinkTime = 5sec,

Population = 15}

{serviceRate = 1000}

{p = 0.05}

{p = 0.05}

{p = 0.02}

{serviceRate = 0.1}

{serviceRate = 0.1}

Mapping from design to analysis domain

• Resources correspond to queues.• Resource demands translate to probabilities or

demand vectors.• Much more complicated mappings will be required to

capture infrastructure details (e.g. performance of containers).

«model»

Design

«model»

QN«DesignToQN»

Requirements?

PIM

PSM

Analysis

EJB MQ server Oracle

Tool:

QN

SPA

SPN

Lifecycle

SLAng

Progress

• SLAng identifies relevant scenarios and technologies.

• Assembling a toolset:– Poseidon UML– MDR plug-in for NetBeans– LUI OCL checker, NEPTUNE project– Libraries and tools for performance analysis

Future work

• Define profiles

• Associate with SLAng constructs

• Create tool to automate analysis

• Integrate into single IDE

• Automate mappings