Performance Testing the Rational Build Agent
On a recent project where we were implementing Rational Team Concert for a large z/OS shop, we were requested for performance metrics for the Rational Build Agent (BLZBFA). The amount of data on existing metics is sparse, but there is some information in the Jazz Deployment Wiki. I found a great article on setting up the build engines and build definitons, and test data. However, this data references the JKE Banking. Based on the client’s request, we needed to use the customer’s actual data due to various things that happen during a build that JKE Banking would not reflect. As such we came up with a ANT script to call and request personal builds. Using an ANT script we can call build requests with different user ID’s, and careful time them them to replicate an anticipated load.
Why personal builds? Because running an identical stream build request would incur build failures as they would be building into the same PDS and same USS directory, and thus we run stream builds on a dedicated build engine, and personal build on multiple dedicated build engines. To make a build engine server only personal build or only stream builds, add a property to the engine, “requestFilter” and it use the values of “personalBuild=false” (no personal builds served by the engine) or “personalBuild=true” (if the engine will just serve personal builds).
Here is a sample of the ANT that we use. Notice the use of the ANT variables. For each request, we have a build properties text file that identifies a build subset, and other parameters that tell the build engine how to run the build. We carefully construct the build subsets using a healthy variety of source types that will call different compilers, precompilers, etc. Running ANT also is easier to manage than recording a performance test from a user interface. This allows us to add <sleep> statements as needed to better simulate real time requests, or remove them and do a full on stress test.
<target name="TestCase1" description="Load test the build environment. ">
<!-- 5 Generate requests for BATCH cobol files -->
<echo>Generating 5 requests for COBOL batch</echo>
<requestTeamBuild userid="${userId1}" password="${password1}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="batch.build.properties" />
<requestTeamBuild userid="${userId2}" password="${password2}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="batch.build.properties" />
<requestTeamBuild userid="${userId3}" password="${password3}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="batch.build.properties" />
<requestTeamBuild userid="${userId4}" password="${password4}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="batch.build.properties" />
<requestTeamBuild userid="${userId5}" password="${password5}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="batch.build.properties" />
<!-- 1 Generate a request with a DCLGEN Copybook -->
<echo>Generate a request with a DCLGEN Copybook</echo>
<requestTeamBuild userid="${userId6}" password="${password6}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="dclgen.build.properties" />
<!-- 12 Generate request for a COBOL DB2 Batch file -->
<echo>Generate 12 requests for a COBOL DB2 Batch file</echo>
<requestTeamBuild userid="${userId7}" password="${password7}" repositoryaddress="${repositoryAddress}" builddefinitionid="${build.id}" personalbuild="true"overridepropertiesfile="cobdb2.build.properties" />
.....
</target>
To build the properties file, just run a subset personal build for the given deployment type. Then, in the build result, open the build.properties file and pull out only the properties you need for the test. The most important ones being:
- team.enterprise.scm.resourcePrefix – the PDS to write to – use ANT variables to make it unique to a user’s PDS, or an individual test run
- team.enterprise.scm.fetchDestination – the USS directory to write to – also use ANT variables to make it unique enough to avoid collisions with other build requests
- team.enterprise.build.ant.buildableSubset – the name of the build subset
- team.enterprise.build.ant.buildableSubsetSlug – a special combination of UUIDs for the build subset and build definition
- team.enterprise.scm.workspaceUUID – the UUID of the repository workspace used by the build engine service ID
George Diaz’s blog:
Parallelizing Personal Dependency Builds https://jorgediazblog.wordpress.com/2013/11/21/parallelizing-personal-dependency-builds/
RTCEE Workload Tests: https://jazz.net/wiki/bin/view/Deployment/RTCEEWorkloadTests
Robin Yehle Bobbitts Blog:
Build engines, build agents, and all that jazz. https://ryehle.wordpress.com/2012/03/26/build-engines-build-agents-and-all-that-jazz/
