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 a CmdlineExitZeroEvent or a CmdlineExitNonzeroEvent 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.

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 a dcos_auth_token definition exists, so you don’t have to specify it through the headers configuration.

Note that a dcos_auth_token can be dynamically injected via an authentication task.

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