Debug JMeter response errors using a JSR223 listener

Understand why you see unusual JMeter errors when running your test in Flood

Sometimes when running a JMeter load test, you may notice an error rate that looks unusual to your results, especially when comparing to a local run of your test in JMeter. To determine the source of the issue, it is best to debug the root cause of this issue under load.​​

Though Flood captures random response samples, they are exactly that - a randomly captured sampled. There is no guarantee that a failing sample will be grabbed from the aggregation or that the sample chosen will hold enough information to triage the root cause easily. ​​

The best option would be to debug under load by using a JSR223 listener with the following Groovy code:

if (prev.isSuccessful() == false) { log.info( "The Sample Label is : " + prev.getSampleLabel()) log.info( "The Start Time in milliseconds is : " + prev.getStartTime()) log.info( "The Response Code is : " + prev.getResponseCode() ) log.info( "The Response Message is : " + prev.getResponseMessage()) log.info( "Headers are: " + prev.getResponseHeaders()) }

The JSR223 listener should be installed at the appropriate level for the issue you are attempting to debug. Install the listener at the test plan level, if the script has multiple thread groups you are attempting to debug. If the test only has one thread group, you can insert it at the thread group level. The following code is going first to review if the sample has failed, and when it finds it has, it will send the details to the JMeter log which can easily be viewed in Flood.​​

The details could be monitored live, and there is no need to wait until the test is done to grab archived results. From the main dashboard click on Logs and get the details of the error.​​

When we recommended to use this option?

• When the error rate is below 20%. We don't recommend you use this method if your error rate is 100%, as the problem should be obvious.

• When the error is only happening under load. When the same problem happens locally with a single/few users, there is no need to use this method.

• When monitoring live output logs for searching errors.