Benchmark definition format
The best authoritative reference will always be the schema; we recommend using Visual Studio Code with schema support.
This document describes the overall structure of the YAML benchmark definition:
Property | Description |
---|---|
name | Name of the benchmark, as later identified in the CLI |
agents | List of one or more agents for clustered runs. This section can be omitted in standalone mode. |
pre | Hooks executed before any benchmark run starts |
post | Hooks executed after any benchmark run terminates |
ergonomics | Utility options that modify scenarios |
http | Configure target servers and HTTP connection options. |
phases | List of phases in this benchmark. |
threads | Number of executors each agent will use. By default it uses only 1 thread for simulating all sessions |
statisticsCollectionPeriod | Each agent collects statistics and sends them to the controller with specified period. Default is 1 second. |
staircase | This is a shortcut for linking phases into a common type of scenario, called staircase as the load is gradually increased in steps. |
Besides these all the options for the constantPerSec
phase type can be embedded into the top-level to allow shorthand benchmark syntax in scenarios with constant load. In that case you cannot use the phases
declaration, though.
Anchors and aliases
Sequences such as logging into the systems will be likely used in different phases/scenarios and it would be tedious to repeat these. That’s where YAML anchors and aliases come into play:
...
phases:
- rampUp:
rampPerSec:
scenario:
- login: &login
- httpRequest:
POST: /login
...
- steadyState:
constantPerSec:
...
scenario:
- login: *login
...
The steps from sequence login
in phase rampUp
will be copied verbatim to sequence login
in phase steadyState
.
The same concept can be applied on whole scenarios:
phases:
- rampUp:
rampPerSec:
...
scenario: &myScenario
- login:
...
- steadyState:
constantPerSec:
...
scenario: *myScenario
And forks as well:
...
phases:
- rampUp:
rampPerSec:
...
forks:
sellShares: &sellShares
weight: 1
scenario: ...
buyShares: &buyShares
weight: 2
scenario: ...
- steadyState:
constantPerSec:
...
forks:
sellShares: *sellShares
buyShares: *buyShares