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.

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:

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

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.

When a bootstrap step imports an experiment from another study, the step copies not only the experiment but also its trials and the system metrics generated during its execution.

The bootstrap step has the following structure:

where the from field should have the following structure:

with:

• study contains the name or id of the study from which to import experiments

• experiments contains the numbers of the experiments from which to import

Examples

The following is an example of a bootstrap step that imports four experiments from two studies:

You can also import all the experiments of a study by omitting the experiments field:

An optimize step generates optimized configurations according to the defined optimization strategy. During this step, Akamas AI is used to generate such optimized configurations.

The optimize step has the following structure:

Optimizer

The optimizer field allows selecting the desired optimizer:

• AKAMAS identifies the standard AI optimizer used by Akamas

• SOBOL identifies an optimizer that generates configurations using

• RANDOM identifies an optimization that generates configurations using random numbers

Notice that SOBOL and RANDOM optimizers do not perform initialization experiments, hence the field numberOfInitExperiments is ignored.

Optimizer 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 longer time) should be used for how many experiments (as a percentage):

where experimentsWithBeta can be:

• A percentage between 0 and 100%

• A number less than or equal to numberOfExperiments

Optimizer options for live studies

For live optimization studies, the optimizerOptions field can be used to specify several important parameters governing the live optimization, which can be defined at the study level and also overridden at the step level (only for steps of type optimize):

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;

• MEDIAN: for each workload, a median of all its values is considered - this works well to find a configuration that is good for the median of all the workloads;

• MOST_VIOLATED: for each workload, the workload of the configuration which results in most violations is considered.

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 constraints 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.

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 delta 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.

Failures

An optimize step is fault-tolerant and tries to relaunch experiments when they fail. Nevertheless, the step imposes a limit on the number of failed experiments: if too many experiments fail, then the entire step fails too. By default, at most 30 experiments can fail while Akamas is optimizing systems. An experiment is considered failed when it either failed to run (i.e., there is an error in the workflow) or violated some constraint.

Inizialitations

An optimize step launches some initialization experiments (by default 10) that do not apply the AI optimizer and are used to find good configurations. By default, the step performs 10 initialization experiments.

Initialization experiments take into account bootstrapped experiments, experiments executed in preset steps, and baseline experiments.

Examples

The following fragment refers to an optimization study that runs 50 experiments using the SOBOL optimizer:

The following fragment refers to an optimization where 50% of the experiments need to use the beta-warping option, which enables a more sophisticated but longer optimization:

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:

where the from field should have the following structure:

with

• study contains the name or id of the study from which to take the configuration. in 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:

Configuration from another study

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

Configuration from the same study

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

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