Gld Configuration

Internal

• gld User Manual

Overview

gld reads its configuration from a YAML file. The file name is specified on command line, as follows:

gld -c <cofiguration-file.yml>

If the configuration file is not specified on command line, gld attempts to look up the value of the GLD_CONF_FILE environment variable and use the value specified there. If both the command line value and the GLD_CONF_FILE environment variable are present, the command line value will take precedence.

The configuration file contains several main sections:

service:

  type: cache|jms|http

  #
  # this is where the target service is configured. The essential piece of configuration 
  # provided in this area is the URL of the service, and the location of the client 
  # libraries. The format depends on the type of the service.
  #

load:

  #
  # specifies the load characteristics, such as number of concurrent threads, 
  # number of operations, etc.
  #

store: 

  #
  # defines the local or remote store for the load that is being generated
  #

output:
   
  #
  # defines how the results are reported
  #

Service Configuration

The service configuration is the section of the configuration file used to specify details of the target service. Essential pieces of configuration that must be present in this section are the type of the service ("cache", "jms", "http", etc.), the service URL and the way gld can locate and load the service's client libraries.

The "type" key is mandatory, it specifies the type of the target service. Available service types are "cache", "jms" and "http".

The type section is followed by the "implementation"and "load-strategy" sections:

service:

  type: cache|jms|http

  implementation: 

    #
    # this is where the extension name, target service URL, a way to 
    # locate client libraries  and other target-specific configuration 
    # details go
    #

  load-strategy:

    #
    # implementation-independent load strategy configuration
    #

The Implementation Section

The configuration details present in the "implementation" section depend on the specific gld extension that is used to provide the client-side functionality. This section contains the extension name, the target service URL, a way to locate client libraries and other target-specific configuration.

The Load Strategy Section

The load strategy section contains implementation-independent load strategy configuration. For example, this is where we specific the sequence of read and write operation for a cache service, or whether we're sending or receiving messages to a JMS service.

Implementation

Implementation Name

The implementation "name" specifies the name of the gld extension that will be instantiated. For more details about extension names, see "Extension Name" section.

service:
  implementation:
    name: <extension-name>

For testing purposes, each service type ships with an "embedded" implementation.

Implementation Class

Optionally, the implementation may be specified by its fully qualified class name:

service:
  implementation:
    class: some.fully.qualified.class.Name

Note that an implementation may be specified either by name or class, but not both. The configuration parsing will fail both the name and the class are found. The class, and its dependents, must be available on the extension class path.

Client Libraries Configuration

Client Libraries Available in the Operational Environment

TODO: replace with a real example

service:
  implementation:
    name: jboss-datagrid-7
    classpath: ${JDG_HOME}/client/hotrod.jar
...

Also see:

Target Service Client Libraries

Client Libraries Shipped with the gld Distribution

TODO: replace with a real example

service:
  implementation:
    name: jboss-datagrid-7
    version: 7.0.0
...

Also see:

Target Service Client Libraries

Load Strategy Configuration

load-strategy:
  name: <load-strategy-name>

  # alternatively, the implementation class can be specified
  class: <fully-qualified-class-name>

read-then-write-on-miss Load Strategy Configuration

service:

  type: cache
  ...

  load-strategy:
    name: read-then-write-on-miss
    reuse-value: false
    

reuse-value

By default, the load strategy randomly generates the first entry value and then keeps reusing it, as a speed optimization (reuse-value: "true"). To change this behavior and configure the load strategy to generate a new random value every times it needs one, set "reuse-value" to "false". Configuring the load strategy to not reuse values will make it somewhat slower.

write-then-read Load Strategy Configuration

service:

  type: cache
  ...

  load-strategy:
    name: write-then-read
    reuse-value: false
    read-to-write|write-to-read: <integer>

reuse-value

See reuse-value above.

Cache Service Configuration

service:

  type: cache
  key-size: 10  # optional, if not specified, the default value is 12 characters
  value-size: 1024  # optional, if not specified, the default value is 512 characters

  implementation: 
      ...

  load-strategy:
    ...

For details on how to configure a specific implementation, see Implementation below.

Known cache extension implementations:

jboss-datagrid-7

jboss-datagrid-7

Load Configuration

service:
  ...
load: 
  threads: 10
  requests|operations|messages: 1000 # optional, if not specified load will be generated forever

Store Configuration

store:

  type: hierarchical
  directory: ../store # if relative, is relative to the position of the configuration file

Output Configuration

Specifies where various types of outputs go. Can be used to configure logging, stdout, stderr and most importantly, the collected statistics.

Statistics Output Configuration

output:
    statistics:
        sampling-interval: 1000
        sampling-task-run-interval: 250
        format: csv
        file: test.csv
        metrics: 
          - TotalPhysicalMemorySize
          - FreePhysicalMemorySize
          - SystemCpuLoad
          - SystemLoadAverage

format

The output format. By default, if not specified is "csv" (comma-separated value).

file

The name of the file to write the output to. If relative, the path will be considered relative to the location of the configuration file. This is a required value, and there is no default.

sampling-interval

The interval (in milliseconds) between successive samples. The default value is 1,000 ms.

sampling-task-run-interval

The interval (in milliseconds) between successive runs of the sampling task. The default value is 250 ms.

metrics

The list of metrics to be read in addition to those configured dynamically. May be not declared, or empty.