Performance Simulation of Runtime Reconfigurable Component-Based - - PowerPoint PPT Presentation

performance simulation of runtime reconfigurable
SMART_READER_LITE
LIVE PREVIEW

Performance Simulation of Runtime Reconfigurable Component-Based - - PowerPoint PPT Presentation

Performance Simulation of Runtime Reconfigurable Component-Based Software Architectures Robert von Massow , Andr van Hoorn , and Wilhelm Hasselbring Software Engineering Group http://se.informatik.uni-kiel.de/ Dept. of Computer Science


slide-1
SLIDE 1

Performance Simulation of Runtime Reconfigurable Component-Based Software Architectures

Robert von Massow, André van Hoorn, and Wilhelm Hasselbring

Software Engineering Group http://se.informatik.uni-kiel.de/

  • Dept. of Computer Science

Christian Albrechts University of Kiel

  • Nov. 25, 2010 @ Palladio Days, Karlsuhe
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

1 / 21

slide-2
SLIDE 2

Context of this Work

Online Capacity Management for Increased Resource Efficiency

Introduction

  • Business-critical software systems
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

2 / 21

slide-3
SLIDE 3

Context of this Work

Online Capacity Management for Increased Resource Efficiency

Introduction

  • Business-critical software systems
  • Quality of service (performance, availability, . . . )
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

2 / 21

slide-4
SLIDE 4

Context of this Work

Online Capacity Management for Increased Resource Efficiency

Introduction

  • Business-critical software systems
  • Quality of service (performance, availability, . . . )
  • Varying workloads + static capacity management
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

2 / 21

slide-5
SLIDE 5

Context of this Work

Online Capacity Management for Increased Resource Efficiency

Introduction

Problem: Overprovisioning — unnecessarily high operating costs Underutilized resources during medium/low workload periods

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

2 / 21

slide-6
SLIDE 6

Context of this Work

Online Capacity Management for Increased Resource Efficiency

Introduction

Problem: Overprovisioning — unnecessarily high operating costs Underutilized resources during medium/low workload periods Goal: Increase resource efficiency while meeting SLAs

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

2 / 21

slide-7
SLIDE 7

Context of this Work

Online Capacity Management for Increased Resource Efficiency

Introduction

Problem: Overprovisioning — unnecessarily high operating costs Underutilized resources during medium/low workload periods Goal: Increase resource efficiency while meeting SLAs ⊲ SLAstic [vHRGH09, vH10]: Online capacity management employing runtime reconfiguration

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

2 / 21

slide-8
SLIDE 8

SLAstic Runtime Reconfiguration Operations

Introduction

1 (De-)Replication of Software Components

C3 C2 C1 C1 C3 C2 C2 C2 C3 C2 C1 C3 C1 N1

...

Nm Nm N1

...

Nm+1

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

3 / 21

slide-9
SLIDE 9

SLAstic Runtime Reconfiguration Operations

Introduction

1 (De-)Replication of Software Components

C3 C2 C1 C1 C3 C2 C2

2 Migration of Software Components

C2 C3 C2 C1 C3 C1 N1

...

Nm Nm N1

...

Nm+1

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

3 / 21

slide-10
SLIDE 10

SLAstic Runtime Reconfiguration Operations

Introduction

1 (De-)Replication of Software Components

C3 C2 C1 C1 C3 C2 C2

2 Migration of Software Components

C2 C3 C2 C1 C3 C1

3 (De-)Allocation of Execution Containers

N1

...

Nm Nm N1

...

Nm+1

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

3 / 21

slide-11
SLIDE 11

Agenda

Introduction

1

Introduction

2

SLAstic — Framework & PCM-Specific Reconfiguration

3

SLAstic.SIM — Simulator Architecture & Framework Integration

4

Evaluation

5

Conclusions

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

4 / 21

slide-12
SLIDE 12

Online Capacity Management Framework

SLAstic — Framework & PCM-Specific Reconfiguration

instrumented, runtime reconfigurable s/w system

SLAstic.CONTROL Analysis

  • nline adaptation engine

...

monitoring records reconfiguration plans reconfiguration

SLAstic. RECONFIGURATION SLAstic. MONITORING

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

5 / 21

slide-13
SLIDE 13

Online Capacity Management Framework

SLAstic — Framework & PCM-Specific Reconfiguration initilization

instrumented, runtime reconfigurable s/w system

SLAstic.CONTROL Analysis

  • nline adaptation engine

...

instrumentation monitoring records reconfiguration plans reconfiguration SLAstic model SLAstic model

SLAstic. RECONFIGURATION SLAstic. MONITORING

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

5 / 21

slide-14
SLIDE 14

Online Capacity Management Framework

SLAstic — Framework & PCM-Specific Reconfiguration

instrumented, runtime reconfigurable s/w system

SLAstic.CONTROL Analysis

  • nline adaptation engine

...

instrumentation initilization monitoring records reconfiguration plans reconfiguration SLAstic model SLAstic model

SLAstic. RECONFIGURATION SLAstic. MONITORING

reconstruction

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

5 / 21

slide-15
SLIDE 15

Reconfiguration Operations (SLAstic/PCM)

SLAstic — Framework & PCM-Specific Reconfiguration

Architecture Level Operation Signatures (based on SLAstic Meta-Model):

replicate (component: AssemblyComponent, to: ExecutionContainer) dereplicate (component: DeploymentComponent)

migrate (component: DeploymentComponent, to: ExecutionContainer) allocate (containerT ype: ExecutionContainerT ype) deallocate (container: ExecutionContainer)

reconfiguration plans

SLAstic. RECONFIGURATION

Technology-specific Operation Signatures (here: PCM [BKR09]):

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

6 / 21

slide-16
SLIDE 16

Reconfiguration Operations (SLAstic/PCM)

SLAstic — Framework & PCM-Specific Reconfiguration

Architecture Level Operation Signatures (based on SLAstic Meta-Model):

1 (De-)Replication of Software Components

  • replicate (component: AssemblyComponent, to: ExecutionContainer)
  • dereplicate (component: DeploymentComponent)

migrate (component: DeploymentComponent, to: ExecutionContainer) allocate (containerT ype: ExecutionContainerT ype) deallocate (container: ExecutionContainer)

reconfiguration plans

SLAstic. RECONFIGURATION

Technology-specific Operation Signatures (here: PCM [BKR09]):

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

6 / 21

slide-17
SLIDE 17

Reconfiguration Operations (SLAstic/PCM)

SLAstic — Framework & PCM-Specific Reconfiguration

Architecture Level Operation Signatures (based on SLAstic Meta-Model):

1 (De-)Replication of Software Components

  • replicate (component: AssemblyComponent, to: ExecutionContainer)
  • dereplicate (component: DeploymentComponent)

migrate (component: DeploymentComponent, to: ExecutionContainer) allocate (containerT ype: ExecutionContainerT ype) deallocate (container: ExecutionContainer)

reconfiguration plans

SLAstic. RECONFIGURATION

Technology-specific Operation Signatures (here: PCM [BKR09]):

ReconfigurationPCM ComponentMigration

  • component : AllocationContext
  • destination : ResourceContainer

ComponentReplication

  • component : AssemblyContext
  • destination : ResourceContainer

ComponentDeReplication

  • component : AllocationContext

ContainerAllocation

  • container : ResourceContainer

ContainerDeAllocation

  • container : ResourceContainer

ReconfigurationPlanPCM 1..*

  • operations
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

6 / 21

slide-18
SLIDE 18

Reconfiguration Operations (SLAstic/PCM)

SLAstic — Framework & PCM-Specific Reconfiguration

Architecture Level Operation Signatures (based on SLAstic Meta-Model):

1 (De-)Replication of Software Components

  • replicate (component: AssemblyComponent, to: ExecutionContainer)
  • dereplicate (component: DeploymentComponent)

2 Migration of Software Components

  • migrate (component: DeploymentComponent, to: ExecutionContainer)

allocate (containerT ype: ExecutionContainerT ype) deallocate (container: ExecutionContainer)

reconfiguration plans

SLAstic. RECONFIGURATION

Technology-specific Operation Signatures (here: PCM [BKR09]):

ReconfigurationPCM ComponentMigration

  • component : AllocationContext
  • destination : ResourceContainer

ComponentReplication

  • component : AssemblyContext
  • destination : ResourceContainer

ComponentDeReplication

  • component : AllocationContext

ContainerAllocation

  • container : ResourceContainer

ContainerDeAllocation

  • container : ResourceContainer

ReconfigurationPlanPCM 1..*

  • operations
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

6 / 21

slide-19
SLIDE 19

Reconfiguration Operations (SLAstic/PCM)

SLAstic — Framework & PCM-Specific Reconfiguration

Architecture Level Operation Signatures (based on SLAstic Meta-Model):

1 (De-)Replication of Software Components

  • replicate (component: AssemblyComponent, to: ExecutionContainer)
  • dereplicate (component: DeploymentComponent)

2 Migration of Software Components

  • migrate (component: DeploymentComponent, to: ExecutionContainer)

3 (De-)Allocation of Execution Containers

  • allocate (containerType: ExecutionContainerType)
  • deallocate (container: ExecutionContainer)

reconfiguration plans

SLAstic. RECONFIGURATION

Technology-specific Operation Signatures (here: PCM [BKR09]):

ReconfigurationPCM ComponentMigration

  • component : AllocationContext
  • destination : ResourceContainer

ComponentReplication

  • component : AssemblyContext
  • destination : ResourceContainer

ComponentDeReplication

  • component : AllocationContext

ContainerAllocation

  • container : ResourceContainer

ContainerDeAllocation

  • container : ResourceContainer

ReconfigurationPlanPCM 1..*

  • operations
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

6 / 21

slide-20
SLIDE 20

Simulation in SLAstic / Goals & Requirements

SLAstic — Framework & PCM-Specific Reconfiguration

Rationale: Simulation-based . . .

1 Study (transient & stationary) effects of reconfigurations (implementation “costly”) 2 Online performance prediction (e.g., proactive problem detection, online planning) 3 Offline performance prediction (e.g., evaluation of adaptation strategies/techniques) 4 Evaluation of overall approach (in addition to lab & case studies)

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

7 / 21

slide-21
SLIDE 21

Simulation in SLAstic / Goals & Requirements

SLAstic — Framework & PCM-Specific Reconfiguration

Rationale: Simulation-based . . .

1 Study (transient & stationary) effects of reconfigurations (implementation “costly”) 2 Online performance prediction (e.g., proactive problem detection, online planning) 3 Offline performance prediction (e.g., evaluation of adaptation strategies/techniques) 4 Evaluation of overall approach (in addition to lab & case studies)

Our Requirements for a Performance Simulator:

1 Architectural style: C-B software systems (assembly, deployment, . . . ) 2 Workload: Replay traces, support varying workload 3 Runtime reconfiguation: Support SLAstic operations 4 Measures: Performance (timing, CPU utilization)

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

7 / 21

slide-22
SLIDE 22

Agenda

SLAstic — Framework & PCM-Specific Reconfiguration

1

Introduction

2

SLAstic — Framework & PCM-Specific Reconfiguration

3

SLAstic.SIM — Simulator Architecture & Framework Integration

4

Evaluation

5

Conclusions

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

8 / 21

slide-23
SLIDE 23

SLAstic.SIM — Architecture & Integration

SLAstic.SIM — Simulator Architecture & Framework Integration

SLAstic. Monitoring SLAstic. Reconfiguration SLAstic.Control

...

instrumented, runtime reconfigurable s/w system

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

9 / 21

slide-24
SLIDE 24

SLAstic.SIM — Architecture & Integration

SLAstic.SIM — Simulator Architecture & Framework Integration

SLAstic. Monitoring SLAstic. Reconfiguration SLAstic.Control Workload traces

SLAstic.SIM

PCM instance monitoring reconfiguration workload Kieker. LogReplayer SimulationCore IMonitoringController IReconfiguration PlanReceiver IMonitoring RecordReceiver ModelManager SimulationController

  • (Initial) transformation of PCM instance into internal representation
  • SLAstic.SIM employs Desmo-J1 [PK05] discrete-event simulation engine
  • Kieker used for providing workload traces and for monitoring simulation data
  • Probes injected with Google Guice2

1http://desmoj.sourceforge.net/

2http://code.google.com/p/google-guice/

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

9 / 21

slide-25
SLIDE 25

Kieker Monitoring & Analysis Framework

SLAstic.SIM — Simulator Architecture & Framework Integration Kieker. Analysis Kieker. Monitoring

Kieker monitoring component Kieker analysis component

M M M M M M

(Java) software system with monitoring probes Online/offline evaluation & visualization Monitoring log e.g., filesystem, database, message-oriented middleware e.g., AOP-based method call interception e.g., trace information, workload, response times, resource utiliz., loop counts

M

e.g., (dynamic analysis) architecture reconstruction, performance evaluation,

  • nline adaptation control,

failure diagnosis

Analysis Plug-In Monitoring Record

Core Characteristics [vHRH+09]

  • Flexible architecture (custom probes, readers, writers, analysis plug-ins)
  • Integrated & extensible record type model for monitoring & analysis
  • Logging, reconstruction, analysis/visualization of (distributed) traces
  • Low overhead (designed for continuous operation in multi-user systems)
  • Evaluated in industry case studies

http://kieker.sourceforge.net

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

10 / 21

slide-26
SLIDE 26

Features/Limitations

SLAstic.SIM — Simulator Architecture & Framework Integration

  • Workload
  • Driven by externally provided workload events (e.g., replayed monitoring logs)
  • Allows integration with workload generators
  • Reconfiguration
  • Triggered by externally provided PCM-specific reconfiguration plans
  • Supports the presented operations
  • Hardware resource scheduling
  • CPU: Procesor-sharing (time slicing)
  • Disk: First-come/first-served
  • Scheduler interface allows custom disciplines
  • Measurements
  • Executions (incl. timing & control-flow information)
  • CPU utilization
  • # Concurrent (system-level) transactions
  • Unsupported PCM features:
  • (Parametric) stochastic expressions −

→ planned

  • Middleware model (as supported by SimuCom)
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

11 / 21

slide-27
SLIDE 27

Agenda

Evaluation

1

Introduction

2

SLAstic — Framework & PCM-Specific Reconfiguration

3

SLAstic.SIM — Simulator Architecture & Framework Integration

4

Evaluation Goals & Methodology Scenario 1 (Constant Workload) Scenario 2 (Varying Workload w/o Reconfiguration) Scenario 3 (Varying Workload w/ Reconfiguration)

5

Conclusions

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

12 / 21

slide-28
SLIDE 28

Evaluation Goals & Methodology

Evaluation ⊲ Goals & Methodology

Goals

  • Evaluating SLAstic.SIM’s performance
  • Comparison with SimuCom (performance & results)
  • Evaluating effect of reconfiguration on the simulated system
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

13 / 21

slide-29
SLIDE 29

Evaluation Goals & Methodology

Evaluation ⊲ Goals & Methodology

Goals

  • Evaluating SLAstic.SIM’s performance
  • Comparison with SimuCom (performance & results)
  • Evaluating effect of reconfiguration on the simulated system

Methodology

  • Use of Bookstore sample application
  • Evaluation scenarios:

1 Constant workload, comparison with SimuCom 2 Varying workload intensity w/o reconfiguration 3 Varying worklaod intensity w/ reconfiguration

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

13 / 21

slide-30
SLIDE 30

Evaluation Goals & Methodology

Evaluation ⊲ Goals & Methodology

Goals

  • Evaluating SLAstic.SIM’s performance
  • Comparison with SimuCom (performance & results)
  • Evaluating effect of reconfiguration on the simulated system

Methodology

  • Use of Bookstore sample application
  • Evaluation scenarios:

1 Constant workload, comparison with SimuCom 2 Varying workload intensity w/o reconfiguration 3 Varying worklaod intensity w/ reconfiguration

Hardware and Software Setup

CPU Intel Core i5, hyper-threading enabled RAM 4 GB OS Ubuntu Generic Linux kernel 2.6.32-22 SMP Java Sun Java Version 1.6.0_20 Heap space 1 GB for SLAstic.SIM / 2 GB for SimuCom 3.0

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

13 / 21

slide-31
SLIDE 31

Bookstore Application — PCM Instance

Evaluation ⊲ Goals & Methodology

1 PCM Repository Model

  • Components & Interfaces
  • RDSEFFS

2 PCM System Model, Resource Env. & Allocation 3 Scenario searchBook()

ICatalog void getBook() Bookstore SEFF <searchBook> CRM SEFF <getOffers> ICRM void getOffers() <<Requires>> <<Requires>> <<Provides>> Catalog SEFF <getBook> <<Provides>> <<Provides>> IBookstore void searchBook() <<Requires>>

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

14 / 21

slide-32
SLIDE 32

Bookstore Application — PCM Instance

Evaluation ⊲ Goals & Methodology

1 PCM Repository Model

  • Components & Interfaces
  • RDSEFFS

2 PCM System Model, Resource Env. & Allocation 3 Scenario searchBook()

<<InternalAction>> formatResults

ResourceDemand

50 <CPU> <<ExternalCallAction>> Required_ICatalog_Bookstore.getBook <<ExternalCallAction>> Required_ICRM_Bookstore.getOffers

RDSEFF of Bookstore.searchBook()

  • Bookstore.searchBook(): External calls: getBook() & getOffers; CPU demand: 50
  • Catalog.getBook(): External call: getBook(); CPU demand: 20
  • CRM.getOffers(): CPU demand: 15
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

14 / 21

slide-33
SLIDE 33

Bookstore Application — PCM Instance

Evaluation ⊲ Goals & Methodology

1 PCM Repository Model

  • Components & Interfaces
  • RDSEFFS

2 PCM System Model, Resource Env. & Allocation 3 Scenario searchBook()

<<CompositeStructure>> theBookstore bookstore <Bookstore> crm <CRM> catalog <Catalog>

System Model

  • Resource Environment: 2 resource containers (Server1 & Server2)
  • (Initial) Allocation: 1 allocation ctx. per assembly ctx. on Server2; Server1 empty
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

14 / 21

slide-34
SLIDE 34

Bookstore Application — PCM Instance

Evaluation ⊲ Goals & Methodology

1 PCM Repository Model

  • Components & Interfaces
  • RDSEFFS

2 PCM System Model, Resource Env. & Allocation 3 Scenario searchBook()

Server2:: bookstore <Bookstore> Server2:: catalog <Catalog> Server2:: crm <CRM> searchBook() getBook() getOffers() getBook()

(reconstructed from simulation data)

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

14 / 21

slide-35
SLIDE 35

Comparison with SimuCom (Scenario 1)

Evaluation ⊲ Scenario 1 (Constant Workload)

Setup

  • Constant workload (log generated by script)
  • Open workload with inter-arrival time 0.1

− → yielding 100% simulated CPU utilization

  • Simulation time: 1000 time units
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

15 / 21

slide-36
SLIDE 36

Comparison with SimuCom (Scenario 1)

Evaluation ⊲ Scenario 1 (Constant Workload)

Setup

  • Constant workload (log generated by script)
  • Open workload with inter-arrival time 0.1

− → yielding 100% simulated CPU utilization

  • Simulation time: 1000 time units

Goal

  • Comparison of results/performance between SLAstic.SIM & SimuCom
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

15 / 21

slide-37
SLIDE 37

Comparison with SimuCom (Scenario 1)

Evaluation ⊲ Scenario 1 (Constant Workload)

Setup

  • Constant workload (log generated by script)
  • Open workload with inter-arrival time 0.1

− → yielding 100% simulated CPU utilization

  • Simulation time: 1000 time units

Goal

  • Comparison of results/performance between SLAstic.SIM & SimuCom

Results (Duration [ms] of 50 simulation runs) Min. Median Mean Max. Dev. SimuCom 6434 7179 7199 7873 287.24 SLAstic.SIM 4864 5325 5333 5833 161.25

(Duration excl. code generation (SimuCom) & initialization (SLAstic.SIM))

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

15 / 21

slide-38
SLIDE 38

Simulation of Varying/Bursty Workload (Scenario 2)

Evaluation ⊲ Scenario 2 (Varying Workload w/o Reconfiguration)

Setup

  • Workload generated (offline) by Apache JMeter2 + own plug-in3
  • Varying inter-arrival times according to an input function
  • 68 653 traces
  • Simulation time: 360 time units

2http://jakarta.apache.org/jmeter/

3http://code.google.com/p/delayfunction/

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

16 / 21

slide-39
SLIDE 39

Simulation of Varying/Bursty Workload (Scenario 2)

Evaluation ⊲ Scenario 2 (Varying Workload w/o Reconfiguration)

Setup

200 400 600 800 1000 1200 1400 1600 1800 50 100 150 200 250 300 350 5000 10000 15000 20000 25000 30000 Tue Wed Thu Fri Sat Sun Mon Inter-arrival time [ms] Arrival rate [requests/sec] Experiment time [s] Emulated day of week Inter-arrival time (per thread) Arrival rate (90 threads)

Varying workload intensity (Scenarios 2 & 3)

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

16 / 21

slide-40
SLIDE 40

Simulation of Varying/Bursty Workload (Scenario 2)

Evaluation ⊲ Scenario 2 (Varying Workload w/o Reconfiguration)

Setup

  • Workload generated (offline) by Apache JMeter2 + own plug-in3
  • Varying inter-arrival times according to an input function
  • 68 653 traces
  • Simulation time: 360 time units

Goal

  • Demonstrating the performance simulation driven by bursty workload

2http://jakarta.apache.org/jmeter/

3http://code.google.com/p/delayfunction/

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

16 / 21

slide-41
SLIDE 41

Simulation of Varying/Bursty Workload (Scenario 2)

Evaluation ⊲ Scenario 2 (Varying Workload w/o Reconfiguration)

Setup

  • Workload generated (offline) by Apache JMeter2 + own plug-in3
  • Varying inter-arrival times according to an input function
  • 68 653 traces
  • Simulation time: 360 time units

Goal

  • Demonstrating the performance simulation driven by bursty workload

Results

  • Simulation took around 18.6 seconds
  • Peak in input workload resulted in peaks of both,

response times & CPU utilization

2http://jakarta.apache.org/jmeter/

3http://code.google.com/p/delayfunction/

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

16 / 21

slide-42
SLIDE 42

Simulation of Varying/Bursty Workload (Scenario 2)

Evaluation ⊲ Scenario 2 (Varying Workload w/o Reconfiguration)

Results (cont’d)

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2)

Response times (searchBook) & CPU utilization

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

16 / 21

slide-43
SLIDE 43

Simulation of Varying/Bursty Workload (Scenario 2)

Evaluation ⊲ Scenario 2 (Varying Workload w/o Reconfiguration)

Results (cont’d)

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2)

Response times (searchBook) & CPU utilization

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 5 10 15 20 Concurrent service requests Simulation time

Concurrent transactions

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

16 / 21

slide-44
SLIDE 44

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Setup

  • Reused varying workload from Scenario 2
  • Simulation time: 360 time units
  • Reconfigurations at t = 200 and t = 300
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-45
SLIDE 45

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Setup

  • Reused varying workload from Scenario 2
  • Simulation time: 360 time units
  • Reconfigurations
  • t = 200: Increase capacity (“weekend plan”)

1

Allocation of Server1

2

Replicating CRM to Server1

3

Migrating Catalog from Server2 to Server1

  • t = 300: Decrease capacity (inverse plan)

1

De-replication of CRM from Server1

2

Migration of Catalog from Server1 to Server2

3

De-allocation of Server1

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-46
SLIDE 46

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Setup

  • Reused varying workload from Scenario 2
  • Simulation time: 360 time units
  • Reconfigurations
  • t = 200: Increase capacity (“weekend plan”)

1

Allocation of Server1

2

Replicating CRM to Server1

3

Migrating Catalog from Server2 to Server1

  • t = 300: Decrease capacity (inverse plan)

1

De-replication of CRM from Server1

2

Migration of Catalog from Server1 to Server2

3

De-allocation of Server1

Goal

  • Demonstrating the effect of reconfiguration
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-47
SLIDE 47

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Setup

  • Reused varying workload from Scenario 2
  • Simulation time: 360 time units
  • Reconfigurations
  • t = 200: Increase capacity (“weekend plan”)

1

Allocation of Server1

2

Replicating CRM to Server1

3

Migrating Catalog from Server2 to Server1

  • t = 300: Decrease capacity (inverse plan)

1

De-replication of CRM from Server1

2

Migration of Catalog from Server1 to Server2

3

De-allocation of Server1

Goal

  • Demonstrating the effect of reconfiguration

Results

  • Simulation took around 18.1 seconds
  • Reconfiguring the system lowered the peaks
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-48
SLIDE 48

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Results (cont’d)

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2) CPU utilization (Server 1) Reconfiguration requests

Response times (searchBook) & CPU utilization

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-49
SLIDE 49

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Results (cont’d)

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2) CPU utilization (Server 1) Reconfiguration requests

Response times (searchBook) & CPU utilization

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 5 10 15 20 Concurrent service requests Simulation time

Concurrent transactions

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-50
SLIDE 50

Varying Workload w/ Reconfiguration (Scenario 3)

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Results (cont’d)

<<execution container>> Server1 <<deployment component>> catalog <Catalog> <<deployment component>> crm <CRM> <<execution container>> Server2 <<deployment component>> bookstore <Bookstore> <<deployment component>> catalog <Catalog> <<deployment component>> crm <CRM> getBook() getOffers() 15567 searchBook() 31015 15567 getBook() 37638 getOffers() 53086 15448 37638 $ 68653

Reconstructed operation dependency graph (deployment view)

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

17 / 21

slide-51
SLIDE 51

Comparison between Scenarios 1 & 2

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Scenario 2 (w/o Reconfiguration):

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2)

Response times (searchBook) & CPU utilization

Scenario 3 (w/ Reconfiguration):

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2) CPU utilization (Server 1) Reconfiguration requests

Response times (searchBook) & CPU utilization

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

18 / 21

slide-52
SLIDE 52

Comparison between Scenarios 1 & 2

Evaluation ⊲ Scenario 3 (Varying Workload w/ Reconfiguration)

Scenario 2 (w/o Reconfiguration):

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2)

Response times (searchBook) & CPU utilization

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 5 10 15 20 Concurrent service requests Simulation time

Concurrent transactions

Scenario 3 (w/ Reconfiguration):

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Response time [x 1/1000] CPU utilization Simulation time Response time (searchBook) CPU utilization (Server 2) CPU utilization (Server 1) Reconfiguration requests

Response times (searchBook) & CPU utilization

2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300 350 5 10 15 20 Concurrent service requests Simulation time

Concurrent transactions

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

18 / 21

slide-53
SLIDE 53

Future Work

Conclusions

  • Implement missing PCM features: Parametric stochastic expressions
  • Evaluation with more complex . . .
  • Models (existing PCM regression examples?)
  • Workloads (from production systems)
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

19 / 21

slide-54
SLIDE 54

Future Work

Conclusions

  • Implement missing PCM features: Parametric stochastic expressions
  • Evaluation with more complex . . .
  • Models (existing PCM regression examples?)
  • Workloads (from production systems)
  • New features
  • Cost model for reconfigurations (e.g., delays for allocation/replication/. . . )
  • Additional strategies for dispatching requests among replicas
  • Additional runtime reconfiguration operations: (e.g., replace implementation [Mat09, Bun08])
  • Additional QoS properties (e.g., reliability of execution containers)
  • Dependency injection (Guice): heavier use & external configuration
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

19 / 21

slide-55
SLIDE 55

Future Work

Conclusions

  • Implement missing PCM features: Parametric stochastic expressions
  • Evaluation with more complex . . .
  • Models (existing PCM regression examples?)
  • Workloads (from production systems)
  • New features
  • Cost model for reconfigurations (e.g., delays for allocation/replication/. . . )
  • Additional strategies for dispatching requests among replicas
  • Additional runtime reconfiguration operations: (e.g., replace implementation [Mat09, Bun08])
  • Additional QoS properties (e.g., reliability of execution containers)
  • Dependency injection (Guice): heavier use & external configuration
  • As usual: Performance ;-)
  • Making SLAstic/SLAstic.SIM available as open source software
  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

19 / 21

slide-56
SLIDE 56

Future Work

Conclusions

  • Implement missing PCM features: Parametric stochastic expressions
  • Evaluation with more complex . . .
  • Models (existing PCM regression examples?)
  • Workloads (from production systems)
  • New features
  • Cost model for reconfigurations (e.g., delays for allocation/replication/. . . )
  • Additional strategies for dispatching requests among replicas
  • Additional runtime reconfiguration operations: (e.g., replace implementation [Mat09, Bun08])
  • Additional QoS properties (e.g., reliability of execution containers)
  • Dependency injection (Guice): heavier use & external configuration
  • As usual: Performance ;-)
  • Making SLAstic/SLAstic.SIM available as open source software

Further Details on this work can be found in our technical report:

Robert von Massow, André van Hoorn, and Wilhelm Hasselbring. Performance simulation of runtime reconfigurable component-based software architectures. Technical Report TR-1015, Department of Computer Science, University of Kiel, Germany, November 2010. http://www.informatik.uni-kiel.de/uploads/tx_publication/tr_1015.pdf.

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

19 / 21

slide-57
SLIDE 57

Literature

Literature

Steffen Becker, Heiko Koziolek, and Ralf Reussner. The Palladio Component Model for model-driven performance prediction. Journal of Systems and Software, 82(1):3–22, 2009. Sven Bunge. Transparentes Redeployment in komponentenbasierten Softwaresystemen (“transparent redeployment in component-based software systems”, in German), December 2008. Diploma Thesis, University of Oldenburg. Jasminka Matevska. Architekturbasierte erreichbarkeitsoptimierte Rekonfiguration komponentenbasierter Softwaresysteme zur Laufzeit. PhD thesis, Department of Computer Science, University of Oldenburg, Oldenburg, Germany, July 2009. Bernd Page and Wolfgang Kreutzer, editors. The Java Simulation Handbook: Simulating Discrete Event Systems with UML and Java. Shaker Verlag, 1. edition, 2005. André van Hoorn. Online Capacity Management for Increased Resource Efficiency of Software Systems. PhD thesis, Dept. Comp. Sc., Univ. Oldenburg, Germany, 2010. work in progress. André van Hoorn, Matthias Rohr, Asad Gul, and Wilhelm Hasselbring. An adaptation framework enabling resource-efficient operation of software systems. In Proc. Warm-Up Workshop for ACM/IEEE ICSE 2010 (WUP ’09), pages 41–44. ACM, April 2009. André van Hoorn, Matthias Rohr, Wilhelm Hasselbring, Jan Waller, Jens Ehlers, Sören Frey, and Dennis Kieselhorst. Continuous monitoring of software services: Design and application of the Kieker framework. Technical Report TR-0921, Dept. Comp. Sc., Univ. Kiel, Germany, November 2009. http://www.informatik.uni-kiel.de/uploads/tx_publication/vanhoorn_tr0921.pdf.

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

20 / 21

slide-58
SLIDE 58

Literature (cont’d)

Literature

Robert von Massow. Performance simulation of runtime reconfigurable software architectures, April 2010. Diploma Thesis, Univ. Oldenburg, Germany. Robert von Massow, André van Hoorn, and Wilhelm Hasselbring. Performance simulation of runtime reconfigurable component-based software architectures. Technical Report TR-1015, Dept. Comp. Sc., Univ. Kiel, Germany, November 2010. http://www.informatik.uni-kiel.de/uploads/tx_publication/tr_1015.pdf.

  • v. Massow, v. Hoorn, Hasselbring (CAU Kiel)

SLAstic.SIM

  • Nov. 25, 2010 @ Karlsruhe

21 / 21