1 of 25

Construct templates

This section describes all the structures that can be used to define resources and objects in Akamas.

Resource

Construct template

System template

Systems are defined using a YAML manifest with the following structure:

# General section
name: Analytical functions
description: A collection of analytical functions

with the following properties:

Field

Type

Value restrictions

Is required

Default Value

Description

Example

The following represents a system (for Cassandra related system)

name: system1
description: my system with 3 nodes of cassandra

Component template

Components are defined using a YAML manifest with the following structure:

name: branin
description: The branin analytical function
componentType: function_branin
properties:
  hostname: function-server

and properties:

Field

Type

Value restrictions

Is required

Default value

Description

Examples

Example of a component for OpenJDK11:

name: JVM_1
description: The first jvm of the system
componentType: java-openjdk-11
properties:
  hostname: ycsb1.dev.akamas.io
  username: ubuntu

Example of a component for the Linux operating system:

name: os_1
description: The operating system of team 1
componentType: Ubuntu-20.04
properties:
  hostname: ycsb1.dev.akamas.io
  username: ubuntu

Parameter template

Parameters are defined using a YAML manifest with the following structure:

with the following properties:

Field

Type

Value restrictions

Is required

Default Value

Description

Notice that parameter definitions are shared across all the workspaces on the same Akamas installation, and require an account with administrative privileges to manage them.

Example

The following represents a set of parameters for a JVM component

The following represents a set of CPU-related parameters for the Linux operating system

Metric template

Metrics are defined using a YAML manifest with the following structure:

metrics:
  - name: "cpu_util"
    description: "cpu utilization"
    unit: "percent"
  - name: "mem_util"
    description: "memory utilization"
    unit: "percent"

and properties:

Field

Type

Value restrictions

Is required

Default Value

Description

Supported units of measure

The supported units of measure for metrics are:

Type

Units

Notice that supported units of measure are automatically scaled for visualization purposes. In particular, for units of information, Akamas uses a base 2 scaling for bytes, i.e., 1 kilobyte = 1024 bytes, 1 megabyte = 1024 kilobytes, and so on. Other units of measure are only scaled up using millions or billions (e.g., 124000000 custom units become 124 Mln custom units).

Component Types template

Component types are defined using a YAML manifest with the following structure:

and properties for the general section:

The parameter section describes the relationship between the component type and already defined parameters with the following properties:

The metric section describes the relationship between the component type and already defined metrics with the following properties:

Notice that component type definitions are shared across all the workspaces on the same Akamas installation, and require an account with administrative privileges to manage them.

Examples

Example of a component for the Cassandra component type:

Example of a component for the Linux operating component type:

Telemetry Provider template

Telemetry Providers are defined using a YAML manifest with the following structure:

with the following properties:

Name

Type

Description

Mandatory

Refer to the page which describes the out-of-the-box Telemetry Providers that are created automatically at Akamas install time.

Telemetry Instance template

Telemetry instances are defined using a YAML manifest with the following structure:

provider: Provider Name
name: My Telemetry
config:
  providerSpecificConfig1: "<value>"
  providerSpecificConfig2: 123
metrics:
- name: metric_name
  datasourceName: datsource_metric_name
  defaultValue: 1.23
  labels:
    - label1
    - label2
  staticLabels:
    staticLabel1: staticValue1
    staticLabel2: staticValue2

with the following properties for the global section

Name

Type

Description

Mandatory

and the metrics section

Workflows template

Workflow are defined using a YAML manifest with the following structure:

with the following properties:

Name

Type

Value Restrictions

Required

Default

Description

The full list of Operators and related options is provided on the pages.

Example

A workflow for the java-based renaissance benchmark application

Study template

Optimization studies are defined using a YAML manifest with the following structure:

with the following mandatory properties:

Some of these optional properties depend on whether the study is an offline or live optimization study.

Number of trials

It is possible to perform more than one trial per experiment to validate the score of a configuration under test, e.g., to consider noisy environments.

The following fragment of the YAML definition of a study sets the number of trials to 3:

Notice: This is a global property of the study which can be overwritten for each step.

Trial aggregation

The trial aggregation policy defines how trial scores are aggregated to form experiment scores.

There are three different types of strategies to aggregate trial scores:

AVG: the score of an experiment is the average of the scores of its trials - this is the default
MIN: the score of an experiment is the minimum among the scores of its trials
MAX: the score of an experiment is the maximum among the scores of its trial

The following fragment of the YAML definition of a study sets the trial aggregation to MAX:

Examples

The following system refers to an offline optimization study for a system modeling an e-commerce service, where a windowing strategy is specified:

The following offline study refers to a tuning initiative for a Cassandra-based system (ID 2)

The following offline study is for tuning another Cassandra-based system (ID 3) by acting only on JVM and Linux parameters

Goal & Constraints

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

where:

Field

Type

Value restriction

Is Required

Default value

Description

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), and 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 compared 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 system under test. For a configuration to be valid for the defined goal, such constraints must be satisfied. Constraints can be defined as absolute or relativeToBaseline.

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%)

As an example, you could define an absolute constraint with the following snippet:

Relative constraints can be defined by adding other constraints under the relativeToBaseline section. In the example below, for the configuration to be considered valid, it's required that the metric jvm.memory_used does not exceed by 80% the value measured in the baseline.

Aggregations

Variables used in the study formula specification and in the constraints definition can include an aggregation. The following aggregations are available: avg, min, max, sum, p90, p95, p99.

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 (containers_benchmark_duration).

Windowing policy

The Windowing field in a study specifies the windowing policy to be adopted to score the experiments of an optimization study.

The two available windowing strategies have different structures:

Trim windowing: trim the temporal interval of a trial, both from the start and the end of a specified temporal amount - this is the default strategy
Stability windowing: discard temporal intervals in which a given metric is not stable and selects the temporal interval in which a metric is maximized or minimized.

In case the windowing strategy is not specified, the entire time window is considered.

Parameter selection

The ParameterSelection field in a study specifies which parameters of the system should be tuned while running the optimization study.

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

A parameter selection can either assume the value of all to indicate that all the available parameters of the system of the study should be tuned, or can assume the value of a list with items of the shape like the one below:

Field

Type

Value restriction

Is required

Default value

Description

Notice that, by default, every parameter specified in the parameters selection of a study is applied. This can be modified, by leveraging the options.

Example

The following fragment is an example:

Metric selection

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

Workload selection

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.

with the following fields:

Field

Type

Value restriction

Is required

Default value

Description

Notice that workload metrics must have been defined in the metricsSelection. Variables used in the name field can include an aggregation. The following aggregations are available: avg, min, max, sum, p90, p95, p99.

Examples

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

Steps

The Steps field in a study specifies the sequence of steps executed while running the study. These steps are run in exactly the same order in which they will be executed.

The following types of steps are available:

Baseline: performs an experiment and sets it as a baseline for all the other ones
Bootstrap: imports experiments from other studies
Preset: performs an experiment with a specific configuration
Optimize: performs experiments and generates optimized configurations

Notice that the structure corresponding to the steps is different for the different types of steps.

Study template

Optimization studies are defined using a YAML manifest with the following structure:

with the following mandatory properties:

Field

Type

Value restrictions

Is required

Default Value

Description

Some of these optional properties depend on whether the study is an offline or live optimization study.

Number of trials

It is possible to perform more than one trial per experiment to validate the score of a configuration under test, e.g., to consider noisy environments.

The following fragment of the YAML definition of a study sets the number of trials to 3:

numberOfTrials: 3

Notice: This is a global property of the study which can be overwritten for each step.

Trial aggregation

The trial aggregation policy defines how trial scores are aggregated to form experiment scores.

There are three different types of strategies to aggregate trial scores:

AVG: the score of an experiment is the average of the scores of its trials - this is the default
MIN: the score of an experiment is the minimum among the scores of its trials
MAX: the score of an experiment is the maximum among the scores of its trial

The following fragment of the YAML definition of a study sets the trial aggregation to MAX:

trialAggregation: MAX    # Other possible values are AVG, MIN

Examples

The following system refers to an offline optimization study for a system modeling an e-commerce service, where a windowing strategy is specified:

system: "bde4f259-9a51-4c67-87aa-3c5bc599c6b9" # id of the system to optimize with the actions defined in this study
workflow: "eshop_jmeter_test" # name of the workflow to use to perform trials
name: Optimizing the e-shop application # name of the study
goal: # the performance goal to achieve
  objective: "maximize"
  function:
    formula: "eshop.payments_per_second"
windowing: # the temporal window in which to compute the score of a trial
  type: "trim"
  trim: ["10s", "0s"] # use the duration of the trial minus 0s from start and end to compute the score of the trial
parametersSelection: "all" # use all available configuration parameters
metricsSelection: "all" # gather all metrics
steps: # the steps to conduct to perform experiments and trials
  - name: "my_baseline" # do first a baseline with the provided configuration
    type: "baseline"
    values:
      jvm.maxHeap: 2048
      jvm.gcType: "-XX:+UseParallelGC"
  - name: my_optimization # then do 20 optimization experiments of 2 trials each
    type: optimize
    numberOfExperiments: 200
    numberOfTrials: 2

The following offline study refers to a tuning initiative for a Cassandra-based system (ID 2)

system: 2
name: Optimizing the cassandra - team 2
goal:
  objective: minimize
  function:
    formula: read_response_time_p90
    variables:
      read_response_time_p90:
        metric: read_response_time_p90
        labels:
          componentName: cassandra

windowing:
  type: trim
  trim: [5m, 1m]

workflow: cassandra_workflow
parametersSelection:
  - name: cassandra_jvm.jvm_maxHeapSize
  - name: cassandra.cassandra_concurrentReads
  - name: cassandra.cassandra_concurrentWrites
  - name: cassandra.cassandra_fileCacheSizeInMb
  - name: cassandra.cassandra_memtableCleanupThreshold
  - name: cassandra.cassandra_concurrentCompactors

steps:
  - name: baseline_step
    type: baseline
    values:
      cassandra_jvm.jvm_maxHeapSize: 1024
      cassandra.cassandra_concurrentReads: 32
      cassandra.cassandra_concurrentWrites: 32
      cassandra.cassandra_fileCacheSizeInMb: 512
      cassandra.cassandra_memtableCleanupThreshold: 0.11
      cassandra.cassandra_concurrentCompactors: 2

  - name: optimization_step
    type: optimize
    optimizer: CALABI
    numberOfExperiments: 50

The following offline study is for tuning another Cassandra-based system (ID 3) by acting only on JVM and Linux parameters

system: 3
name: Optimizing a Cassandra NoSQL database version 3 (jvm + os parameters)
goal:
  objective: minimize
  function:
    formula: (x1+x2)/2
    variables:
      x1:
        metric: write_response_time_p90
        labels:
          componentName: cassandra_team1
      x2:
        metric: read_response_time_p90
        labels:
          componentName: cassandra_team1

windowing:
  type: trim
  trim: [8m,2m]

numberOfTrials: 2
workflow: cassandra_workflow_jvm_os

parametersSelection:
  - name: JVM1.jvm_maxHeapSize
  - name: JVM1.jvm_newRatio
  - name: JVM1.jvm_survivorRatio
  - name: JVM1.jvm_maxTenuringThreshold
  - name: JVM1.jvm_gcType
  - name: JVM1.jvm_concurrentGCThreads
  - name: os1.os_cpuSchedMinGranularity
  - name: os1.os_cpuSchedWakeupGranularity
  - name: os1.os_CPUSchedMigrationCost
  - name: os1.os_CPUSchedChildRunsFirst
  - name: os1.os_CPUSchedLatency

steps:
  - name: baseline_step
    type: baseline
    values:
      JVM_team1.jvm_maxHeapSize: 1024
      JVM_team1.jvm_newRatio: 2
      JVM_team1.jvm_survivorRatio: 8
      JVM_team1.jvm_maxTenuringThreshold: 15
      JVM_team1.jvm_gcType: UseConcMarkSweepGC
      JVM_team1.jvm_concurrentGCThreads: 8
      os_team1.os_cpuSchedMinGranularity: 3000000
      os_team1.os_cpuSchedWakeupGranularity: 4000000
      os_team1.os_CPUSchedMigrationCost: 500000
      os_team1.os_CPUSchedChildRunsFirst: 0
      os_team1.os_CPUSchedLatency: 24000000

  - name: optimization_sobol
    type: optimize
    optimizer: SOBOL
    numberOfExperiments: 3

  - name: optimization_calabi
    type: optimize
    optimizer: CALABI
    numberOfExperiments: 50

Goal & Constraints

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

where:

Field

Type

Value restriction

Is Required

Default value

Description

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:

function:
  formula: "jvm1.response_time / sqrt(x:max)"
  variables:
    x:
      metric: "throughput"
      labels:
        componentName: "jvm2"

Where:

Field

Type

Value restrictions

Is required

Default value

Description

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), and 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

Each metric that is directly or indirectly part of the formula of the function of the Goal is aggregated by default by average; more specifically, Akamas computes the average of each metric within the time window specified by the of the Study. Variables in the formula can be expanded with an aggregation in the form of <variable>:<aggreggation>. A list of available aggregations is available in the section .

Variables

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:

Field

Type

Value restrictions

Is required

Default value

Description

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

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%)

As an example, you could define an absolute constraint with the following snippet:

goal:
  objective: "minimize"
  function:
    formula: "jvm.response_time"
  constraints:
    absolute:
      - name: heap_used
        formula: jvm.heap_used <= 3221225472

goal:
  objective: "minimize"
  function:
    formula: "jvm.response_time"
  constraints:
    absolute:
      - name: heap_used
        formula: jvm.heap_used <= 3221225472
    relativeToBaseline:
      - name: memory_used
        formula: jvm.memory_used <= 80%

Aggregations

Examples

goal:
    objective: "maximize"
    function:
      formula: "jpetstore.elements_per_second"
    constraints:
      absolute:
        - name: elements_per_second
          formula: "jpetstore.elements_per_second > 55"
        - name: max_duration
          formula: "jpetstore.max_duration < 800"
        - name: avg_duration
          formula: "jpetstore.avg_duration < 70"
        - name: error_rate
          formula: "jpetstore.error_rate < 0.01"

goal:
  objective: "minimize"
  function:
    formula: "containers_memory_limit/containers_benchmark_duration:max"
    variables:
      containers_memory_limit:
        metric: "memory_limit"
        labels:
          appId: "app1"
      containers_benchmark_duration:
        metric: "benchmark_duration"
        labels:
          appId: "app1"

Baseline step

A baseline step performs an experiment (a baseline experiment) and marks it as the initial experiment of a study. The purpose of the step is to build a reference configuration that Akamas can use to measure the effectiveness of an optimization conducted towards a system.

A baseline step offers three options when it comes to selecting the configuration of the baseline experiment:

Use a configuration made with the default values of the parameters taken from the system of the study
Use a configuration taken from an experiment of another study
Use a custom configuration

The baseline step has the following structure:

Field

Type

Value restriction

Is required

Default value

Description

where the from field should have the following structure:

study: "study_from_which_to_take_the_baseline"
experiments: [1]

with

study contains the name or ID of the study from which to take the configuration
experiments contains the number of the experiment from which to take the configuration

Examples

Baseline configuration with default values

Default values for the baseline configuration only require setting the name and type fields:

name: "my_baseline"    # name of the step
type: "baseline"       # type of the step (baseline)

Baseline configuration from another study

The configuration taken from another study to be used as a baseline only requires setting the from field:

name: "my_baseline"   # name of the step
type: "baseline"      # type of the step (baseline)
from:
  - study: "study_from_which_take_the_baseline" # name or id of the study from which to take the configuration
    experiments: [1]  # the number of the experiment from which to take the configuration

Notice: the from and experiments fields are defined as an array, but can only contain one element.

Custom baseline configuration

The custom configuration for the baseline only requires setting the values field:

name: "my_baseline"         # name of the step
type: "baseline"            # type of the step (baseline)
values:
  jvm1.maxHeapSize: 1024    # parameter maxHeapSize of jvm1 is set to 1024
  jvm2.maxHeapSize: 2048    # parameter maxHeapSize of jvm2 is set to 2048

Preset step

A preset step performs a single experiment with a specific configuration. The purpose of this step is to help you quickly understand how good is a particular configuration.

A preset step offers two options when selecting the configuration of the experiment to be executed:

Use a configuration taken from an experiment of a study (can be the same study)
Use a custom configuration

The preset step has the following structure:

Field

Type

Value restrictions

Is required

Default value

Description

where the from field should have the following structure:

study: "study_preset_1"
experiments: [1]

with

study contains the name or ID of the study from which to take the configuration. In the case this is omitted, the same study of the step is considered for experiments from which taking configurations
experiments contains the number of the experiment from which to take the configuration

Examples

Custom configuration

You can provide a custom configuration by setting values:

name: "my_preset"   # name of the step
type: "preset"      # type of the step (preset)
values:
  jvm1.maxHeapSize: 1024 # parameter maxHeapSize of jvm1 is set to 1024
  jvm2.maxHeapSize: 2048 # parameter maxHeapSize of jvm2 is set to 2048

Configuration from another study

You can select a configuration taken from another study by setting from:

name: "my_preset"  # name of the step
type: "preset"     # type of the step (preset)
from:
  - study: "preset_study_1" # name or ID of the study from which to take the configuration
    experiments: [1] # the number of the experiment from which to take the configuration

Configuration from the same study

You can select a configuration taken from the same study by setting from but by omitting the study field:

name: "my_preset"    # name of the step
type: "preset"       # type of the step (preset)
from:
  - experiments: [1] # the step will take the configuration of the experiment #1 of the same study of the step

Notice: the from and experiments fields are defined as a list, but can only contain one element.

Optimizer Options

The Optimizer Options is a set of parameters used to fine-tune the study optimization strategy during the optimize step.

Optimizer options have the following structure:

Field

Type

Value restrictions

Description

Options for both online and offline studies

Safety Factor

The safetyFactor field specifies how much the optimizer should stay on the safe side in evaluating a candidate configuration with respect to the goal constraints. A higher safety factor corresponds to a safer configuration, that is a configuration that is less likely to violate goal constraints.

Acceptable values are all the real values ranging between 0 and 1, with (safetyFactor - 0.5) representing the allowed margin for staying within the defined constraint:

0 means "no safety", as with this value the optimizer totally ignores goal constraint violations;
0.5 means "safe, but no margin", as with this value the optimizer only tries configurations that do not violate the goal constraints, by remaining as close as possible to them;
1 means "super safe", as with this value the optimize only tries configurations that are very far from goal constraints.

For live optimization studies, 0.6 is the default value, while for offline optimization studies, the default value is 0.5.

Options for offline studies

For offline optimization studies, the optimizerOptions field can be used to specify whether beta-warping optimization (a more sophisticated optimization that requires a longer time) should be used and for how many experiments (as a percentage):

# Half the experiments should be done with beta-warping
experimentsWithBeta: "50%"

where experimentsWithBeta can be:

A percentage between 0 and 100%
A number less than or equal to numberOfExperiments

Options for live studies

For live optimization studies, the optimizerOptions field can be used to specify several important parameters governing the live optimization:

optimizerOptions:
  onlineMode: RECOMMEND                    # [RECOMMEND|FULLY_AUTONOMOUS]
  safetyMode: GLOBAL                       # [GLOBAL|LOCAL]
  workloadOptimizedForStrategy: MAXIMIN    # [MAXIMIN|LAST|MOST_VIOLATED]
  safetyFactor: 0.55                       # 0 <= safetyFactor <= 1
  explorationFactor: 0.05                  # 0 <= explorationFactor <= 1 or FULL_EXPLORATION

Notice that while available as independent options, the optimizer options onlineMode (described here below), workloadOptimizedForStrategy (here below) and the safetyFactor (see above) work in conjunction according to the following schema:

All these optimizer options can be changed at any time, that is while the optimization study is running, to become immediately effective. The Optimizer options commands page in the reference guide provides these specific update commands.

Online Mode

The onlineMode field specifies how the Akamas optimizer should operate:

RECOMMEND: configurations are recommended to the user by Akamas and are only applied after having been approved (and possibly modified) by the user;
FULLY AUTONOMOUS MODE: configurations are immediately applied by Akamas.

Safety Mode

The safetyMode field describes how the Akamas optimizer should evaluate the goal constraints on a candidate configuration for that configuration to be considered valid:

GLOBAL: the constraints must be satisfied by the configuration under all observed workloads in the configuration history - this is the value taken in case onlineMode is set to RECOMMEND;
LOCAL: the constraints are evaluated only under the workload selected according to the workload strategy - this should be used with onlineMode set to FULLY_AUTONOMOUS.

Notice that when setting the safetyMode to LOCAL, the recommended configuration is only expected to be good for the specific workload selected under the defined workload strategy, but it might violate constraints under another workload.

Workload Strategy

The workloadOptimizedForStrategy field specifies the workload strategy that drives how Akamas leverages the workload information when looking for the next configuration:

MAXIMIN: the optimizer looks for a configuration that maximizes the minimum improvements for all the already observed workloads;
LAST: for each workload, the last observed workload is considered - this works well to find a configuration that is good for the last workloads - it is often used in conjunction with a LOCAL safety mode (see here above);
MOST_VIOLATED: for each workload, the workload of the configuration with more violations is considered.

Exploration Factor

The explorationFactor field specifies how much the optimizer explores the (unknown) optimization space when looking for new configurations. For any parameter, this factor measures the difference between already tried values and the value of a new possible configuration. A higher exploration factor corresponds to a broader exploration of never-tried-before parameter values.

Acceptable values are all the real values ranging between 0 and 1, plus the special string FULL_EXPLORATION:

0 means "no exploration", as with this value the optimizer chooses a value among the previously seen values for each parameter;
1 means "full exploration, except for categories", as with this value the optimizer for a non-categorical parameter any value among all its domain values can be chosen, while only values (categories) that have already been seen in previous configurations are chosen for a categorical parameter;
FULL_EXPLORATION means "full exploration, including categories" as with this value the optimizer chooses any value among all its domain values, including categories, even if not already seen in previous configurations.

In case the desired explorationFactoris 1 but there are some specific parameters that also need to be explored with respect to all its categories, then PRESET steps (refer to the Preset step page) can be used to run an optimization study with these values. For an example of a live optimization study where this approach is adopted see Optimizing a live full-stack deployment (K8s + JVM).

Example

The following fragment refers to an optimization study that runs 100 experiments using the SOBOL optimizer and forces 50% of the experiments to use the beta-warping option, enabling a more sophisticated but longer optimization:

name: "my_optimize"  # name of the step
type: "optimize"     # type of the step (optimize)
optimizer: "SOBOL"
numberOfExperiments: 100  # amount of experiments to execute
numberOfTrials: 2         # amount of trials for each experiment
optimizerOptions:
  experimentsWithBeta: "50%"

Construct templates

System template

Example

Component template

Examples

Parameter template

Example

Metric template

Supported units of measure

Component Types template

Examples

Telemetry Provider template

Telemetry Instance template

Workflows template

Example

Study template

Number of trials

Trial aggregation

Examples

Goal & Constraints

Function

Formula

Variables

Constraints

Aggregations

Examples

Windowing policy

Parameter selection

Example

Metric selection

Example

Workload selection

Examples

Steps

System template

Example

Metric template

Supported units of measure

Construct templates

Component template

Examples

Telemetry Instance template

Workflows template

Example

Component Types template

Examples

Parameter template

Example

Telemetry Provider template

Study template

Number of trials

Trial aggregation

Examples

Goal & Constraints

Function

Formula

Variables

Constraints

Aggregations

Examples

Workload selection

Examples

Parameter selection

Example

Steps

Windowing policy

Metric selection

Example

Trim windowing

Example

Baseline step

Examples

Baseline configuration with default values

Baseline configuration from another study

Custom baseline configuration

Bootstrap step

Examples

Stability windowing

Example

Preset step