Errors Table Report Item¶
The errors table provide details about each error which occurred during the test. It allows to understand what happened server-side during the load test.
The table displays:
- The time of the error,
- The HTTP action that raised the error,
- The HTTP error message,
- The related failed assertions.
To view the error details:
- Find the error you want to inspect,
- Click on the Magnifier button on the right.
- A panel displays the detailed error.
Warning
The table doesn't display all the errors for performance and storage space reasons.
Edit Table¶
To customize the Errors Table, please refer to the documentation page about the legend and metrics.
The Errors Table only have one specific metric to display errors. So when editing it you can only select the following filters:
Export as CSV¶
To export the table as a CSV files, please refer to the documentation page about exporting tables.
View Error¶
Each error can be inspected to display detailed information:
- Number of errors: the number (and percentage) of this error message compared to the total hits on this request,
- Occurred at: the exact time at which the error occurred,
- In region: in which region the error has occurred,
- On virtual user: which user profile and associated virtual users raised the error,
- On container: the parent container of the action that failed,
- On action: action which failed,
- Message: the HTTP error message,
- Connect time, latency ans response time: statistics related to the request in error.
An additional table displays the potential assertions that failed for the request.
And the Request and Response panels displays the request which has been sent to the server, and the received response.
Info
You can search for Strings or Regular Expressions (JavaScript format) inside the request and response:
- Click on a code text area (headers or body),
- Type CTRL + F (or CMD + F on Mac), a dialog appears on top of the area,
- Type the text to search or a regex,
- Press Enter to start searching for the first term occurrence
- Press CTRL + G (or CMD + G on Mac) to find the next occurrence, or SHIFT + CTRL + G (or SHIFT + CMD + G on Mac) to find the previous one.
Understanding errors¶
Failure criterias¶
An error is triggered when:
- The response code is
4XX
or5XX
, - There is no response code (JMeter internal error message),
- An assertion failed.
If you compare this to the virtual user validation, we are in the same situation than when there is no recorded content to compare the response with.
Displayed errors¶
To avoid overloading our reporting interface, we only store up to 2 errors for each combination of:
- Load generator
- Request
- Response code
This way if a particular requests encounters two different response codes during the same test, you would see at least one of each in the Error table. While maintaining a manageable size for the error table at the same time.
4XX and 5XX codes¶
These codes can mean one of two things:
- The application is failing,
- The test scripts are incorrect.
Now to understand which one you are facing takes some analysis, using assertions can help pinpoint the failure accurately. Since we only display the requests that failed, assertions are a good way to make sure you provoke the failure at the right place. For instance, you could see an issue with a payment in the error table when in fact it's your login that failed earlier.
No response codes¶
When there is no response code, JMeter will output the error message in the response body. In OctoPerf we typically show a response header like this:
HTTP/1.1 -1 - UNKNOWN
Now this can mean several things, it could be an issue with your scripts, for instance if a variable fails to be evaluated in the path, you might get something like this:
java.net.URISyntaxException: Illegal character in path at index 39: https://petstore.octoperf.com/actions/${path}
But most of the time it is just related to the server not answering our requests. Because of this JMeter has no response code to display and it show an error message instead.
Network errors¶
When the application becomes hard to reach or even completely unreachable during the test, you might experience one of these response messages:
javax.net.ssl.SSLException: Connection reset
javax.net.ssl.SSLException: Socket closed
java.net.SocketTimeoutException: Read timed out
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
org.apache.http.NoHttpResponseException: XXXXX failed to respond
org.apache.http.conn.HttpHostConnectException: Connect to XXXXX failed: Connection timed out
All of these indicate that the remote server was either not answering or rejected our request. We take action to prevent such errors to occur because of our load generators. If the threshold table is empty, then look for issues on the network path between our agents and your servers.
To mitigate these issues, you can also try to increase the number of retries by editing properties.
Warning
We do not recommend doing this since network issues indicate bottlenecks that should be analyzed.
Routing errors¶
When the load generator cannot find a path to the application, you will face a message like this one:
java.net.NoRouteToHostException: No route to host
This indicates that your application requires whitelisting to be accessed, try whitelisting the IP range of a particular AWS location or get in touch with OctoPerf sales team to purchase a dedicated IP.