Home

This repository contains plugins that estimate the performance parameters of Palladio Component Models (PCM) iteratively, e.g. resource demands, branch probability and the number of loop iterations.

For this goal, the monitoring data which are affected by an iterative source code change are used. We use a decision tree to build a predictive model for branch transitions and regression analysis to build a predictive model for loop iterations and resource demands. These predictive models can include dependency relations to service call arguments.

To estimate resource demands iteratively, we must know all resource demands that are executed in a system. We monitor only a part of a system during one iteration and must estimate which resource demands are executed, but not monitored. We use the previously estimated performance model parameters and the control flow information of services to traverse the control flow in order to detect non-monitored resource demands.

Setup

You can use Eclipse Oxygen.3a release (4.7.3a) or a later release.

The following plugins must be installed from their update sites.

• Instrumentation Record Language - https://build.se.informatik.uni-kiel.de/eus/mdm/snapshot/
• Palladio - https://sdqweb.ipd.kit.edu/eclipse/palladiosimulator/releases/1.1.0/
• JaMoPP - http://update.jamopp.org/trunk/
• Vitruv - http://vitruv.tools/updatesite/nightly
• maeven from Eclipse update site: --m2e: a Maven integration in Eclipse for dependency management and search. --m2e connector for maven archiver pom properties --m2e connector for the Maven Dependency Plugin

Please make sure to activate IRL Code Generation after installing the IRL compiler. For the configuration, you must visit in the properties dialog of a project. Open the Kieker IRL section and check the two tabs for Compiler and Targets. The first allows defining the location of the code generation, while the second allows activating various generators. Choose the java generator. You must also activate the generators via the Eclipse preferences dialog.

Code Style

The files clean-up.xml and formatter.xml under the repository root define the code style of java files and can be imported in eclipse.

Project Sources

The main project sources are located under the directory /bundles and the tests under the directory /tests.

SEFF Parameter Estimation

The following projects contain the logic for estimating SEFF Parameters, like loop iterations, branch probabilities and resource demands.

• The project tools.vitruv.applications.pcmjava.modelrefinement.parameters contains the analysis part of the SEFF parameter estimation. Monitoring records are read and we estimate Stochastic Expressions based on them. The class SeffParameterEstimation is the main entry point. For example usage see the following test project.
• The project tools.vitruv.applications.pcmjava.modelrefinement.parameters.monitoring contains logic which is needed by instrumented code, in order to produce monitoring records. The main class is ThreadMonitoringController. For example usage, see the following test project.
• The project tools.vitruv.applications.pcmjava.modelrefinement.parameters.tests contains tests and evaluations, using the previous described projects. The project contains example java applications for generating monitoring records, located in the package monitoring.tests. The unit tests in the package tools.vitruv.applications.pcmjava.modelrefinement.parameters use additional data located in the directory test-data. Examine the class SeffParameterEstimationTest for the usage of the main component SeffParameterEstimation. The unit tests can be executed only as plugin java unit tests in eclipse.

Architecture

The following figures describe the architecture of the SEFF Parameter estimation. The components diagram shows the dependencies between the different components and their interfaces. The functionality is divided into five components. The main component Seff Parameter Estimation delegates the tasks to further components.

Components The component diagram shows the dependencies between the different components and their interfaces. The Seff Parameter Estimation component, for example, depends on interfaces, which the Loop Estimation, Branch Estimation and Resource Demand Estimation components provide.

The Seff Parameter Estimation component calls the Loop Estimation, Branch Estimation, and Resource Demand Estimation components. The Resource Demand Estimation needs the Utilization Estimation component, which requests predictions from the Loop Estimation, Branch Estimation, and Resource Demand Estimation components. The following figure depicts the call sequence between the components.

Call Sequence The sequence diagram illustrates the interactions between the components. For example the Seff Parameter Estimation calls the Loop Estimation component. The frame multiple indicates that the included interactions may occur multiple times.

The following diagram shows the different interfaces, which the components implemented. The component Seff Parameter Estimation depends on the interfaces BranchEstimation, LoopEstimation and ResourceDemandEstimation. These interfaces have the single method update, which is responsible for updating the passed PCM repository by setting the Stochastic Expressions of BRanches, Loops and Resource Demands. The component Resource Demand Estimation depends on the interface ResourceUtilizationEstimation. This interface has the single method estimateRemainingRemainingUtilization, which is responsible for estimating the utilization of the monitored internal actions, by predicting the utilization of not monitored internal actions and subtract them from the actually measured utilization,. The component Utilization Estimation depends on the interfaces ResourceDemandPrediction, LoopPrediction and BranchPrediction. These interfaces have a single method, which is responsible for predictions. These predictions are required by the Utilization Estimation component, in order to predict a control flow and which not monitored internal actions are executed.

Component Interfaces This diagram shows the interfaces in detail, which the components implement and depend on. For example, the Branch Estimation component implements the interfaces BRanchEstimation and BranchPrediction and the Resource Demand Estimation depends on the interface ResourceUtilizationEstimation.

The following class diagram shows the different monitoring records. These records are defined via the Kieker Instrumentation Record Language (IRL). The abstract template RecordWithSession contains common fields and references a ServiceCallRecord via its serviceExecutionId field.

Monitoring Records The class diagram shows the different monitoring records. The RecordWithSession is an abstract template, which the other records extend. The RecordWithSession references a ServiceCallRecord via its serviceExecutionId field.

The following component diagram shows the Kieker records reading pipeline. The records are read by the Kieker FSReader from the filesystem, then passed to the Kieker Session Filter, which filters the sessionId field of the records. The filtered records are passed to the Kieker Loop Filter, Kieker Branch Filter, Kieker Response Time Filter, Kieker Service Call Filter and Kieker Resource Utilization Filter. These filters store the records in memory and implement DataSet interfaces, via which the estimation components access the data.

Monitoring Records Reader The following component diagram shows the Kieker records reading pipeline and how a record is passed through. The Kieker FSReader, for example, passes records to the Kieker Session Filter.