Configurations is the element of benchmark configuration file which lists all configurations that are to be ran on clusters.
Each configuration has its own
config element containing as many
setup elements as is necessary to cover all specified groups of any cluster.
Setup element attributes
plugin (required) - specifies which plugin will be ran on the group (or cluster if no groups are used)
group (optional) - specifies which group the setup is for, required if the groups are used in clusters configuration
The plugins themselves define their own configuration format in their separate namespaces, but there are two elements defined by core RadarGun. These values apply only to slave VM, if plugin spawns another VM the handling of arguments and varibles for that VM depends on plugin implementation (they are usually defined in separate element).
- Note: These values are not applied to slave instances you start, slaves get automatically restarted after the configuration is distributed to them by master.
Setup core elements
vm-args (optional) - defines VM arguments (there is a number of child elements, please refer to the schema file) environment (optional) - defines VM environment variables in key-value pairs
Following examples fully apply only to their respective plugins.
This configurations element contains single config which will initialize
infinispan52 plugin on all slaves (as there are no group definitions) and have it run in embedded mode (node inside slave VM) using “dist-sync.xml” file as configuration source.
- The method used to obtain plugin configuration files (where applies) depends entirelly on plugin implementation, there is no central distribution so the user has to make file available to plugin otherwise (copy to slave machine/place on the shared drive/…)
- Among other places, most plugins tend to look for the files inside their own folder in
confsubfolder, placing it there is a safe bet
Not entirely basic configuration
This configuration element contains two configs, each with two setups for different groups (groups have to be defined in clusters element). The first config will run
infinispan70 plugin, the second config will run
infinispan90 plugin, with groups having distinct configuration files and cache configuration.
This configuration element has only one config with two defined groups,
client. This configuration takes advantage of properties.
Server group will run
infinispan90 plugin in server mode - it will start Infinispan server as separate process and manage it.
Arguments will hame following effect:
- home - path to Infinispan server installation
- server-zip - plugin is to lookup Infinispan release zip file on specified path and unpack it into home, useful to ensure clean installation for each run
- ISPN_ZIP_PATH is assumed to be defined as environment property
- env - environment variables that will be set for server VM
- args - VM arguments that will be given to server
- jboss.node.name - specifies a server node name
- jboss.socket.binding.port-offset - specifies offset for server port binding, making sure servers do not compete for same ports on localhost
Client group will run
infinispan90 plugin in HotRod mode - a java client library over specialized protocol.
Arguments will have following effect:
- vm-args - slave VM will be limited to maximum if 1 Gigabyte of memory
- servers - HotRod client will connect to ISPN servers on specified addresses/ports. This configuration assumes only two servers.
Notes: Notice the difference between args and vm-args elements, former is used as configuration for the server, while the latter is used as configuration for the slave instance.
Sometimes when comparing very similar configurations with complex setup these configurations differ by only few details. Such repetition is error-prone, and therefore RadarGun supports configuration templates:
template here works as a standalone template for the
setup element. You can see that it is possible to chain templates to form a hierarchy, too.
The configuration that’s later in the hierarchy can override any configuration from the parent template; this has some limitations, though, such as not being able to append one element to a list (e.g. the
vm-args) - you need to override the whole list.