View on GitHub

RadarGun

Benchmarking framework for data grids and distributed caches

Configurations

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).

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.

Basic configuration

    <configurations>
      <config name="Infinispan 5.2 - distributed">
        <setup plugin="infinispan52" >
          <embedded xmlns="urn:radargun:plugins:infinispan52:3.0" file="dist-sync.xml"/>
        </setup>
      </config>
    </configurations>

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.

Not entirely basic configuration

    <configurations>
      <config name="Infinispan 7.0 - distributed">
        <setup plugin="infinispan70" group="g1">
          <embedded xmlns="urn:radargun:plugins:infinispan70:3.0"
            file="dist-no-tx_site1_70.xml" cache="testCacheSite1" />
        </setup>
        <setup plugin="infinispan70" group="g2">
          <embedded xmlns="urn:radargun:plugins:infinispan70:3.0"
            file="dist-no-tx_site2_70.xml" cache="testCacheSite2" />
        </setup>
      </config>
      <config name="Infinispan 9.0 - distributed">
        <setup plugin="infinispan90" group="g1">
          <embedded xmlns="urn:radargun:plugins:infinispan70:3.0"
            file="dist-no-tx_site1_90.xml" cache="testCacheSite1" />
        </setup>
        <setup plugin="infinispan90" group="g2">
          <embedded xmlns="urn:radargun:plugins:infinispan70:3.0"
            file="dist-no-tx_site2_90.xml" cache="testCacheSite2" />
        </setup>
      </config>
    </configurations>

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.

Complex configuration

    <configurations>
      <config name="ISPN9 - hotrod">
        <setup group="server" plugin="infinispan90">
          <server xmlns="urn:radargun:plugins:infinispan90:3.0" file="streaming.xml"
            jmx-domain="jboss.datagrid-infinispan" start-timeout="120000" cache-manager-name="clustered">
            <args>
              -Djava.net.preferIPv4Stack=true
              -Djboss.node.name=node${slave.index}
              -Djboss.socket.binding.port-offset=${slave.index}00
            </args>
            <home>${env.RG_WORK}/slave${slave.index}</home>
            <server-zip>${env.ISPN_ZIP_PATH}/infinispan-server-9.0.0-SNAPSHOT.zip</server-zip>
            <env>JAVA_OPTS=-server -Xms2g -Xmx4g
              -XX:MaxPermSize=4G
              -verbose:gc
            </env>
          </server>
        </setup>
        <setup group="client" plugin="infinispan90">
          <hotrod xmlns="urn:radargun:plugins:infinispan90:3.0">
            <servers>127.0.0.1:11222,127.0.0.1:11322</servers>
          </hotrod>
          <vm-args>
            <memory max="1G" />
          </vm-args>
        </setup>
      </config>
    </configurations>

This configuration element has only one config with two defined groups, server and 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:

Client group will run infinispan90 plugin in HotRod mode - a java client library over specialized protocol.
Arguments will have following effect:

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.

Configuration templates

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:

    <configurations>
      <template name="common">
        <vm-args>
           <!-- long list of JVM arguments -->
        </vm-args>
        <default xmlns="urn:radargun:plugins:infinispan80:3.0">
          <!-- another complex configuration -->
        </default>
      </template>
      <template name="a" base="common">
        <default xmlns="urn:radargun:plugins:infinispan80:3.0">
          <!-- change something in here -->
        </default>
      </template>
      <template name="b" base="common">
        <default xmlns="urn:radargun:plugins:infinispan80:3.0">
          <!-- change something else -->
        </default>
      </template>
      <config name="8.0 A">
        <setup plugin="infinispan80" base="a" />
      </config>
      <config name="8.0 B">
        <setup plugin="infinispan80" base="b" />
      </config>
      <config name="9.0 A">
        <setup plugin="infinispan90" base="a" />
      </config>
      <config name="9.0 B">
        <setup plugin="infinispan90" base="b" />
      </config>
    </configurations>

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.