Optimization goals and constraints are defined using a YAML manifest with the following structure:

where:

Function

The function field of the Goal of a Study details the characteristics of the function Akamas should minimize or maximize to reach the desired performance objective.

The function field has the following structure:

Where:

Formula

The formula field represents the mathematical expression of the performance objective for the Study and contains variables and operators with the following characteristics:

• Valid operators are: + - * / ^ sqrt(variable) log(variable) max(variable1, variable2) min(variable1, variable2)

• Valid variables are in the form:

  • <component_name>.<metric_name>, which correspond directly to metrics of Components of the System under test

  • <variable_name>, which should match variables specified in the variables field

Variables

The variables field contains the specification of additional variables present in the formula, variables that can offer more flexibility with respect to directly specifying each metric of each Component in the formula.

Notice: each subfield of variables specifies a variable with its characteristics, the name of the subfield is the name of the variable.

The variable subfield has the following structure:

It is possible to use the notation <component_name>.<metric_name> in the metric field to automatically filter the metric’s data point by that component name is applied.

Constraints

The constraints field specifies constraints on the metrics of the components of the system under test that need to be satisfied for a configuration to be valid with respect to the defined goal.

Each constraint has the form of:

mathematical_operationcomparison_operatorvalue_to_compare

where valid mathematical operations include:

• + - * / ^

• min max

• sqrt log (log is a natural logarithm)

valid comparison operators include:

• > < <= >=

• == != (equality, inequality)

and valid values to compare include:

• absolute values (e.g, 104343)

• percentage values relative to the baseline (e.g, 20%)

Examples

The following example refers to a study whose goal is to optimize the throughput of a Java service (jpetstore), that is to maximize the throughput (measured as elements_per_second) while keeping errors (error_rate) and latency (avg_duration, max_duration) under control (absolute values):

The following example refers to a study whose goal is to optimize the memory consumption of Docker containers in a microservices application, that is to minimize the average memory consumption of Docker containers within the application of appId="app1" by observing memory limits, also normalizing by the maximum duration of a benchmark (container_benchmark_duration).

A windowing policy of type trim trims the temporal interval of a trial, both from the start and from the end of a specified temporal amount (e.g., 3 seconds).

The trim windowing has the following structure:

In case a windowing policy is not specified, the default windowing corresponding to trim[0s,0s] is considered.

Example

The following fragment shows a windowing strategy of type "trim" where the time window is specified to start 10s after the beginning of the trial and to end immediately before the end of the trial:

windowing: # the temporal window in which to compute the score of a trial
  type: "trim" # type of windowing is trim
  trim: [10s, 0s]

The MetricSelection field in a study specifies the metrics of the system. Such selection has only the purpose to specify which metrics need to be tracked while running the study and does not affect the optimization.

In case this selection is not specified, all metrics are considered.

A metrics selection can either assume the value of all to indicate that all the available metrics of the system of the study should be tracked, or can assume the value of a list of the names of metrics of the system that should be tracked prepended with the name of the component.

Example

The following fragment is an example:

metricsSelection:
  - application.response_time
  - application.error_rate
  - jvm1.gc_time

The workloadsSelection is a structure used to define the metrics that are used by Akamas to model workloads as part of a live optimization study.

workloadsSelection:
  - name: component1.metric1
  - name: component2.metric2:p95

with the following fields:

Notice that workload metrics must have been defined in the metricsSelection.

Examples

The following refers to a workload represented by the metric transactions_throughput of the konakart component:

workloadsSelection:
  - name: konakart.transactions_throughput