Despite our best efforts, we have all been there before. That load test that just concluded generated thousands of errors that it shouldn’t have. It could have been a miscalculation or a shifted decimal place on estimated traffic volumes; or rather it was a configuration setting on the target machines that was overlooked. Regardless, we wish we could have intercepted that test early in its execution, possibly saving valuable time, data charges, and virtual machine costs. Wouldn’t it be nice if there was a setting that we could tick to automatically stop a JMeter load test upon x number of errors encountered? Or better yet, after x number of a certain type of error?
If you were wondering if this is possible, this blog post will come as good news. There isn’t a JMeter setting, but with a few lines of BeanShell or Groovy inside your test plan, we will show you step-by-step how to automatically stop a JMeter load test upon generating too many errors, and even provide you with some interesting suggestions on how you can take this automation a step further.
The basic structure of our simple test plan which is covered step-by-step below.
How to stop a JMeter load test in a few easy steps:
Step 1. Create a test plan
Create a new JMeter test plan containing a few basic elements. We will need a regular Thread Group to contain our test, and to that we will add a “Once Only Controller” and a “Loop Controller”:
Step 2. Add initial controller
Under our “Once Only Controller”, we’ll want to add a “BeanShell Preprocessor” containing the following script.
For convenience you can copy and paste these lines as follows:
vars.put("__threshold", "10");
vars.put("__count", "0");
vars.put("__loopCount", "100");
This will set us up to run one-hundred requests, however as you will see later, __threshold will cause the test to abort upon encountering ten HTTP errors.
Step 3. Make it loop
Moving to our “Loop Controller” we will want to set the “Loop Count” field to ${__loopCount} as depicted below. JMeter will automatically pull this value as we have set it in the previous step, making it convenient to configure our test from a single location.
Step 4. Add a web request
Still under our “Loop Controller”, we will want to add an “HTTP Request” (here aptly named “Error-Prone HTTP Request”) that will likely generate an error for the purposes of our demonstration. To achieve this, we have specified a web address which does not resolve, though any request that generates an error (e.g., 404 not found, 500 internal error, etc.) will do. You can also see in the screen capture below that we have added a “Flow Control Action” which is an optional step to delay each request by 500ms simply to make execution slow enough that we can follow along as our test runs.
Step 5. Add the conditional logic
This is where we will add the error detection and test termination logic. Under our “Loop Controller” we will want to add a “BeanShell Postprocessor” containing the following lines of scripting:
For convenience you can copy and paste these lines as follows:
int __count = Integer.parseInt(vars.get("__count"));
int __threshold = Integer.parseInt(vars.get("__threshold"));
int responseCode;
try {
responseCode = Integer.parseInt(prev.getResponseCode());
}
catch (Exception ex) {
responseCode = 0;
}
boolean errorResponse = ((responseCode < 200) ||
(responseCode >= 400) || (prev.getErrorCount() > 0));
if (errorResponse) {
__count = __count + 1;
}
log.warn( "Errors = " + __count );
if (__count >= __threshold) {
log.warn("Maximum number of errors reached, aborting test.");
ctx.getEngine().stopTest();
}
vars.put("__count", String.valueOf(__count));
Step 6. Prove we can stop a JMeter load test
From the “Options” menu, you may want to select “Log viewer” which will show the output from our JMeter test as we run in GUI mode to debug. In the lower pane of JMeter shown in the screen capture below, you can easily see that our test generates errors which are accumulated in our __count variable and upon reaching the value of 10 specified in __threshold, the test terminates despite not reaching the preconfigured number of iterations.
This example was purposely crafted in a simple manner to most easily convey the concept of how to stop a JMeter load test early based on certain error conditions. We chose to use any HTTP response that generated a web exception or was not a 200 or 300 series code. The determination of what constitutes the error is entirely at your discretion as it relates to your specific design requirements. You may even consider intercepting this condition to interface with a messaging service to send an alert, as you will likely be preoccupied with the enjoyment that this type of automation brings. See how easy it is to implement this how-to guide with a free RedLine13 trial subscription.