Channels¶
The channel
classes are applying the test values to the application being
tested. They are responsible for translating the modification of the scalar test
parameter to one or more actions that need to be taken in order to implement the test.
After a channel has applied the values, the Observers are used to extract useful events from the application for further processing.
For example, the CmdlineChannel is re-starting the application with a different command-line, every time the test parameters have changed.
CmdlineChannel¶
-
class
performance.driver.classes.channel.
CmdlineChannel
(*args, **kwargs)[source]¶ The Command-line Channel launches an application, passes the test parameters through command-line arguments and monitors it’s standard output and error.
channels: - class: channel.CmdlineChannel # The command-line to launch. cmdline: "path/to/app --args {{macros}}" # [Optional] The standard input to send to the application stdin: | some arbitrary payload with {{macros}} in it's body. # [Optional] Environment variables to define env: variable: value other: "value with {{macros}}" # [Optional] The directory to launch this app in cwd: "{{marathon_repo_dir}}" # [Optional] The script to use for teardown teardown: stop_daemon # [Optional] If set to `yes` the app will be launched as soon # as the driver is up and running. atstart: yes # [Optional] If set to `yes` (default) the app will be re-launched # if it exits on it's own. restart: yes # [Optional] If set to `yes` the "cmdline" expression will be evalued # in a shell. shell: no # [Optional] The time between the SIGINT and the SIGKILL signal gracePeriod: 10s # [Optional] Change the `kind` of log messages emitted by this channel # instead of using the default 'stdout' / 'stderr' kind: stdout: custom_out stderr: custom_err
When a parameter is changed, the channel will kill the process and re-launch it with the new command-line.
For every line in standard inout or output, a
LogLineEvent
is emitted with the contents of the line.When the application launched through this channel exits the channel can take two actions depending on it’s configuration:
- If
restart: yes
is specitied (default), the channel will re-launch the application in oder to always keep it running. - If
restart: no
is specified, the channel will give up and publish aCmdlineExitZeroEvent
or aCmdlineExitNonzeroEvent
according to the exit code of the application.
Note
Note that if there are no
{{macro}}
defined anywhere in the body of the configuration this channel will not be triggered when a parameter is updated and thus the application will never be launched.If you still want the application to be launched, use the
atstart: yes
parameter to instruct the channel to launch the application at start.- If
HTTPChannel¶
-
class
performance.driver.classes.channel.
HTTPChannel
(*args, **kwargs)[source]¶ The HTTP Channel performs an HTTP Requests when a parameter changes.
channels: - class: channel.HTTPChannel # The URL to send the requests at url: http://127.0.0.1:8080/v2/apps # The body of the HTTP request body: | { "cmd": "sleep 1200", "cpus": 0.1, "mem": 64, "disk": 0, "instances": {{instances}}, "id": "/scale-instances/{{uuid()}}", "backoffFactor": 1.0, "backoffSeconds": 0 } # [Optional] The HTTP Verb to use (Defaults to 'GET') verb: POST # [Optional] The HTTP headers to send headers: Accept: text/plain # [Optional] How many times to re-send the request (can be # a macro value) repeat: 1234 # [Optional] How long to wait between re-sends (in seconds) # If missing the next request will be sent as soon as the previous # has completed repeatInterval: 1234 # [Optional] For which event to wait before re-sending the request. repeatAfter: event
When a parameter is changed, a new HTTP request is made. If a
repeat
parameter is specified, the same HTTP request will be sent again, that many times.Various events are published from this channel, that can be used to synchronise other components or track metrics.
- When an HTTP request is initiated an
HTTPRequestStartEvent
is published. - When an HTTP request is completed and the response is pending, an
HTTPFirstRequestEndEvent
is published. - When the HTTP response is starting, an
HTTPFirstResponseStartEvent
is published. - When the HTTP response is completed, an
HTTPResponseEndEvent
is published.
If you are using the
repeat
configuration parameter you can also use the following events:- When the first HTTP request is started, the
HTTPFirstRequestStartEvent
is published. - When the last HTTP request is started, the
HTTPLastRequestStartEvent
is published. - When the first HTTP request is completed, the
HTTPFirstRequestEndEvent
is published. - When the last HTTP request is completed, the
HTTPLastRequestEndEvent
is published. - When the first HTTP response is started, the
HTTPFirstResponseStartEvent
is published. - When the last HTTP response is started, the
HTTPLastResponseStartEvent
is published. - When the first HTTP response is completed, the
HTTPFirstResponseEndEvent
is published. - When the last HTTP response is completed, the
HTTPLastResponseEndEvent
is published.
Therefore it’s possble to track the progress of the entire repeat batch, aswell as the progress of an individual HTTP event.
Note
This channel will automatically inject an
Authorization
header if adcos_auth_token
definition exists, so you don’t have to specify it through theheaders
configuration.Note that a
dcos_auth_token
can be dynamically injected via an authentication task.- When an HTTP request is initiated an
MarathonUpdateChannel¶
-
class
performance.driver.classes.channel.
MarathonUpdateChannel
(config, eventbus)[source]¶ The Marathon Update Channel is performing arbitrary updates to existing apps, groups or pods in marathon, based on the given rules.
channels: - class: channel.MarathonUpdateChannel # The base url to marathon url: "{{marathon_url}}" # One or more updates to perform update: # `patch_app` action is updating all or some applications # and modifies the given properties - action: patch_app # The properties to patch patch: instances: 3 # [Optional] Update only application names that match the regex. # If missing, all applications are selected. filter: "^/groups/variable_" # [Optional] Update at most the given number of apps. # If missing, all applications are updated. limit: 10 # [Optional] Shuffle apps before picking them (default: yes) shuffle: no # [Optional] Additional headers to include to the marathon request headers: x-Originating-From: Python
When a parameter is changed, the channel will kill the process and re-launch it with the new command-line.
MarathonDeployChannel¶
-
class
performance.driver.classes.channel.
MarathonDeployChannel
(*args, **kwargs)[source]¶ The Marathon Deploy Channel is performing one or more deployment on marathon based on the given rules.
channels: - class: channel.MarathonDeployChannel # The base url to marathon url: "{{marathon_url}}" # [Optional] Retry deployments with default configuration retry: yes # [Optional] Retry with detailed configuration retry: # [Optional] How many times to re-try tries: 10 # [Optional] How long to wait between retries interval: 1s # One or more deployments to perform deploy: # The type of the deployment - type: app # The app/pod/group spec of the deployment spec: | { "id": "deployment" } # [Optional] Repeat this deployment for the given number of times repeat: 10 repeat: "{{instances}}" repeat: "{{eval(instances * 3)}}" # [Optional] How many deployments to perform in parallel # When a deployment is completed, another one will be scheduled # a soon as possible, but at most `parallel` deployment requests # will be active. This is mutually exclusive to `burst`. parallel: 1 # [Optional] [OR] How many deployments to do in a single burst # When all the deployments in the burst are completed, a new burst # will be posted. This is mutually exclusive to `parallel. burst: 100 # [Optional] Throttle the rate of deployments at a given RPS rate: 100 # [Optional] Stall the deployment for the given time before placing # the first HTTP request delay: 10s