6.2.x

Use request method in merge rules.

XLT 6.2.1

See here for a complete list of all changes.

Test Framework

  • XLT comes with some small optimizations regarding CPU and memory usage.
  • When building the class path from the test suite files uploaded to the load agents, XLT now also searches directory build/dependency for additional JAR files. This new directory better fits the directory structure that is typical for Gradle-based test suites.

XLT Jenkins Plug-In

XLT now ships with the latest version 2.0.1 of the XLT Jenkins plug-in. This version fixes an issue when executing the same Jenkins project/job multiple times in parallel.

XLT 6.2.0

See here for a complete list of all changes.

Test Framework

Incorrect response size reported in real-browser tests

Previously, our timer recorder extensions for Chrome and Firefox might report an incorrect value for the size of a response. The reason is that this value relied on the received Content-Length header which, however, might not be present at all. Now the extensions use the transferSize metric obtained from the browser and fall back to the content length only if this metric is not available.

UnknownHostException with dnsjava-based host name resolver

XLT may use dnsjava as an alternative DNS resolver. The dnsjava-based implementation queries either one of the configured name servers or the system’s default name server if no specific server was configured. The latter did not work reliably on Windows so dnsjava might end up with no name server, resulting in an UnknownHostException. Fixed now.

Load Testing

Use request method in merge rules

Especially when load-testing REST-based APIs, XLT may record requests which have the same URL, but differ in the HTTP request method only. Since the runtime behavior may be very different for each method, it is essential to evaluate these requests not as a whole, but per request method.

To this end, the request processing framework in the report generator has been extended by a new filter (type code m) that filters requests by HTTP method. Use this filter in request processing rules to split requests into different buckets by qualifying the request name with the respective request method.

See below for how some typical request processing rules would look like:

# append HTTP method to request name
com.xceptance.xlt.reportgenerator.requestMergeRules.11.newName = {n} [{m}]
com.xceptance.xlt.reportgenerator.requestMergeRules.11.stopOnMatch = false

# append HTTP method to request name for OPTIONS requests only
com.xceptance.xlt.reportgenerator.requestMergeRules.11.newName = {n} [{m}]
com.xceptance.xlt.reportgenerator.requestMergeRules.11.methodPattern = OPTIONS
com.xceptance.xlt.reportgenerator.requestMergeRules.11.stopOnMatch = false

To enable filtering requests by HTTP method, XLT will always record the request method to timers.csv from now on. Previously, it was recorded only if the property com.xceptance.xlt.results.data.request.collectAdditionalRequestInfo = true was set.

Run start command independently from upload command

The XLT master controller supports a command line interface to trigger the various stages of a load test (upload, start, abort, download, report) via scripts.

Previously, start did not work without upload, i.e. the two commands had to be combined:

mastercontroller.sh -c upload,start

However, sometimes it would be nice if we could prepare everything beforehand (uploads may take a while) and later just start the load test, for example to begin load testing exactly at a certain time:

mastercontroller.sh -c upload
mastercontroller.sh -c start

The start command can now be run separately in non-interactive mode. Please ensure that you have uploaded the test suite before or otherwise the load test will finish immediately.

Note that in interactive mode you still have to upload a test suite before you can start the load test.

Last modified May 30, 2022