Learning How to Share

Ideally, a load testing lab is set up such that each tester is using their own machine (physical or virtual) for the DevOps Test workbench; however, this is not always possible. Be aware that configuration becomes more complicated when you need to share. That configuration is the subject of our discussion here. These notes would apply to both DevOps Test Performance and DevOps Test UI.

For the purposes of our discussion, our test team will consist of Thomas, Eileen, Pooja and Kristoff. They are a test team sharing a server machine on which DevOps Test Performance is installed.

Workspaces

All users must be sure they are not using the same workspace as someone else. When trying share a workspace, there is no way to avoid test asset contention and eventually general workspace corruption. If you need to share assets, work out an export/import routine or implement a version control utility, such as Git.

Ports

The DevOps Test products rely on specific ports for specific features, such as recording tests and working with datasets. If your testing team is going to run concurrent instances of the DevOps Test workbench, you will need to do some tuning to avoid port conflicts.  These port conflicts may not cause overt error messages, instead they can cause strange behaviors.

Port information for each workspace is controlled by preferences. Navigate to Window > Preferences > Test > Server and you will see details for Unsecure port and Secure port. The default values for the ports are 7080 and 7443, respectively.

Thomas, Eileen, Pooja and Kristoff cannot all use the same ports at the same time. It is a very good idea to maintain a central chart detailing who uses which ports, something like this:

Every.Single.Time you create a workspace, you must visit Window > Preferences > Test > Server to modify your Unsecure port and your Secure port. Modifying your Unsecure port will also silently change your dataset server port (which is set to <Unsecure port> + 1).

Agents

We are going to assume that server on which you have multiple testers opening workbenches is “SharedServer.MyDomain.com”.

Agent-to-server communication is driven by the majordomo.config file. If you installed using all the defaults, then you will find that file at C:\Program Files\IBM\DevOpsTest\Majordomo\majordomo.config.

The default content of the file:

<MajordomoConfig xmlns="http://www.example.org/MajordomoConfiguration">
    <debug>false</debug>
    <canonicalHostName></canonicalHostName>
    <ipAddress></ipAddress>
    <pollInterval>10</pollInterval>
    <workbenches>
        <hostName>localhost</hostName>
        <port>7080</port>
    </workbenches>
    <servers>
        <hostName></hostName>
        <port></port>
        <token></token>
        <slug></slug>
    </servers>
</MajordomoConfig>

The <workbenches>…</workbenches> section contains host and port information for your workbench(es). The default is localhost:7080. This default setup will poll the localhost on port 7080 periodically to indicate its availability.

It can be set up to poll more than one workbench; in fact, that’s what needs to happen when Thomas, Eileen, Pooja and Kristoff are all working on the same shared server.

<MajordomoConfig xmlns="http://www.example.org/MajordomoConfiguration">
    <debug>false</debug>
    <canonicalHostName></canonicalHostName>
    <ipAddress></ipAddress>
    <pollInterval>10</pollInterval>
    <workbenches>
        <hostName>SharedServer.MyDomain.com</hostName>
        <port>7080</port>
    </workbenches>
    <workbenches>
        <hostName>SharedServer.MyDomain.com</hostName>
        <port>7085</port>
    </workbenches>
    <workbenches>
        <hostName>SharedServer.MyDomain.com</hostName>
        <port>7090</port>
    </workbenches>
    <workbenches>
        <hostName>SharedServer.MyDomain.com</hostName>
        <port>7095</port>
    </workbenches>
   <servers>
        <hostName></hostName>
        <port></port>
        <token></token>
        <slug></slug>
    </servers>
</MajordomoConfig>

Now the agent’s Majordomo service will poll each of the workbenches on the shared server, using the proper port number for each user’s workbench.

Wrapping it up

For all the detail provided above, it’s preferable that your lab not operate this way. Running concurrent workbenches can be a drain on your system resources because each instance of the workbench is allocated a default maximum 4Gb of heap space, and sometimes the size of test assets calls for that maximum to be raised. If the shared server only has 16Gb of RAM, it’s easy to see how your 4 concurrent workbench users might quickly exceed that. Best to allot each user their own machine. However, if you do have a need to work this way, take care in configuring accordingly.