Gld Configuration
Internal
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
This section contains the extension name, target service URL, a way to locate client libraries and other target-specific configuration.
The Load Strategy Section
"type" is mandatory, it specifies the type of service. Possible values:
- "cache" (see Cache Service Configuration below for specifics)
- "jms"
- "http"
Implementation
The implementation section defines the gld extension to use. The extension contains implementation-specific details essential to connect to, and interact with the target service.
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:
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:
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.
read-to-write
write-to-read
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
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.