Optimize Pro has been deprecated.
But you can check out Optimize Live:
A parameter is an input to an experiment which can be adjusted from trial to trial. Every parameter has a name and a range of acceptable values. The value given to a parameter in a specific trial is sometimes called the parameter assignment.
An experiment must define one or more parameters. Together, the parameters in an experiment define the search space.
The parameter spec must contain a name and a value range.
Optionally, a baseline value may be specified.
If a baseline value is specified, it will be used for the first trial and be tagged with the label
This value will be used in the UI to provide a comparison between the metrics measured in subsequent trials.
Additional details for the parameter spec can be found in the parameter API reference.
Integer parameters specify a minimum bound, a maximum bound, or both. Both bounds are inclusive, and when either bound is unspecified, it defaults to 0. A parameter for tuning CPU on a container might be defined with both bounds:
- name: cpu
While a parameter for tuning the concurrent garbage collection threads on a Java application might be defined with only a
- name: con_gc_threads
Note: Some fields in Kubernetes objects, such as CPU Request, allow their value to be specified using decimal numbers, such as
0.1, or as an integer with an attached unit, such as
100m (“one hundred millicpus”).
Because StormForge Optimize only tunes integer numbers, you must use the latter format.
String parameters specify a finite list of acceptable values, where each value is a string. For example, a parameter for tuning the garbage collection algorithm on a Java application might be defined like:
- name: gc_collector
Constraints restrict the assignments that parameters may take relative to one another.
Constraints are optional and used in addition to the bounds on individual parameters, such as
The order constraint requires that one integer parameter be strictly larger than another. For example, you can use an order constraint to ensure that a container’s maximum replicas value is always greater than it’s minimum replicas:
The sum constraint requires that the sum of two or more parameters not exceed an upper or lower bound.
For example, in an experiment tuning CPU on multiple deployments, a sum constraint could enforce an overall cap of
4000 millicpus between both deployments:
- name: first_cpu
- name: second_cpu
Each parameter in the sum constraint may have an associated weight. When a weight is specified for a parameter, the parameter’s value is multiplied by that weight before being summed.
Now that you understand what parameters are and how they can be used, let’s see what they look like in an example
In this example, suppose you’ve decided to tune the frontend and product catalog services CPU and memory resources. These values will become our parameters. You’ll use the existing resource requests as your baseline. This should give you an idea of what the current site can handle. You’ll set the search space as 50-1000 (millicores) for your services CPU. You’ll set the search space as 16-512 (MB) for your services memory.