Resolving Errors

To View Errors That Occurred in Tests

Possible Causes of Errors

How to Resolve Errors

SLA Violations

"Load Testing Validation Failed" Errors

Authentication Errors

"Connection Was Not Simulated" Errors

Timeout Errors

"Connection Was Closed" And "Connection Was Simulated Partially" Errors

"Connection Reset by Peer" Errors

"Failed to Extract Any Value for the Variable" Errors

"Did not receive data from" Errors

Errors Occurring Under Mass Load

Ask for Assistance, if Needed

• During the test run, open the Runtime > Message page. View the list of errors that has occurred during the test run.

– or –

• After the test run is over, on a graph in the Report panel, click the needed data point on the Errors series. View the list of errors that occurred at that moment.

– or –

• After the test run is over, open the Details panel. It contains a full list of errors that occurred during the test run.

LoadComplete reports errors for various reasons. For example:

• The test engine cannot connect to the tested web site.

• The site works incorrectly under the load.

• The logic of the server's functioning has changed, and the server rejects requests that have obsolete parameters.

• The service level agreement (SLA) criteria are violated.

• Validation of the response data failed.

• Authentication failed.

• Other reasons, including errors posted by the Custom Message operation.

To analyze errors that occurred during a load test, you need to know the internal structure of the tested web application, as well as the specifics of the server that hosts the application. Therefore, the assistance of the application developers and server administrator may be very useful.

To find the cause of a problem, view the error details. You can also use additional sources of information, like web server logs, operating system logs, your web application’s logs and so on.

To fix an error:

1. After the test run is over, open the Detailed test log. It contains information on all the operations simulated during the test run.

2. Find the request simulated with an error. LoadComplete marks such requests with the icon.

   Note:

   You can filter the contents of the Details panel to find the needed request faster. To view only the requests simulated with errors, select Show Error items on the panel’s toolbar and clear the Show OK items and Show Warnings items check boxes. See Filtering Results Data.

3. Analyze the error message posted for the request. It describes the problem:

   

   Click the image to enlarge it.

4. To find a possible reasons of the error, you can examine the Request Body and Response Body panels. They contain the data LoadComplete sent to the server during the test run and the data it received from the server as a response.

5. Your further actions depend on the error type. The rest of the topic provides more information on this.

When LoadComplete reports that the service level agreement criteria were violated, this means that the tested web server’s performance was at an unacceptable level.

SLA violation errors are not in fact errors: LoadComplete simulates requests successfully, however, the expected page load time, time to the first byte, or duration exceeds the specified limit. View the SLA violations on the Messages page or in the Detailed test log to learn the expected and the actual page load time, time to the first byte, or duration.

The following factors can cause SLA violations:

• The server performance is not fast enough. Consult the server administrator to find the cause of the server’s poor performance.

• The SLA criteria are too strict. Review the SLA criteria and correct them if needed. For information on how to set correct criteria, see Setting Reasonable Goals for Service Level Agreement.

You define SLA criteria:

• For a load test - On the SLA page of the test. LoadComplete applies them to all the pages and requests of scenarios the test simulates.

• For individual pages, requests and other operations - In the Scenario editor. These criteria override the test criteria. LoadComplete also uses them during scenario verification.

When LoadComplete reports a validation failure, it means that the value retrieved from a server response does not match the expected value.

The following factors can cause a validation failure:

• The tested web application returns incorrect data. Ask the application developers for help in finding the cause of the problem.

• You have specified an incorrect expected value. Specify the appropriate value and condition on the Validations tab of the Scenario editor.

• Your data selector works incorrectly. If you use a data selector to extract data from a server response, you may need to check whether your data selector works correctly. See How to Determine What Data a Selector Extracts.

If LoadComplete reports authentication errors, you need to inform the developers and find a solution together with them. Here are some tips:

• Check the network authentication protocol - LoadComplete supports the following protocols:

  • Basic

  • Digest

  • NTLM

  • Kerberos

  • Negotiate

  • OAuth

  • FBA

  Other authentication protocols are currently not supported.

• Verify that the authentication protocol’s API is available - To simulate authenticated access, LoadComplete can use Security Support Provider Interface (SSPI). To run load tests successfully, you must have appropriate SSPI support components installed in your operating system.

  • The Basic and NTLM authentication protocols are available in all the operating systems supported by LoadComplete.

  • The Kerberos and Negotiate authentication protocols are available in all the operating systems supported by LoadComplete and require the <Windows>\system32\secur32.dll library.

  • The Digest authentication protocol is available in all the operating systems supported by LoadComplete and requires the <Windows>\system32\wdigest.dll library.

• Verify the server name in the Authentication table - If your tested web server supports the Negotiate, NTLM, Kerberos or Digest authentication, make sure that the server is added to the Authentication table in your project and that the table specifies the server’s name correctly.

  Various servers may apply different notation rules to specify the server names. For example, the testserver short name may not be an equivalent to the full name - testserver.domain.com.

  If the names are specified incorrectly, LoadComplete will be unable to use the provided authentication information and the Details panel will contain warning messages like the one below:

  Unable to find credentials for the "HOST_NAME" host which the tested server requested. These data are not specified in the Authentication Information table…

  In the Server column of the Authentication table, enter exactly the same host names as those mentioned in the error message. These names are displayed according to the naming convention used on the server you are testing.

• Check whether the Details panel shows the SSPI error code - When the Security Support Provider Interface returns a code other than "success", LoadComplete posts an error message and the appropriate error code to the Details panel. For example:

  Connection 0: SSL negotiation failed. Error 0x80090308.

  The published error codes are declared in the Winerror.h file and are used in all the versions of the Microsoft Windows operating system. For more information about the occurred error and its cause, refer to the Winerror.h file description in MSDN.

If LoadComplete reports that a connection was not simulated and there is no information on simulated requests, the cause can be one of the following:

• The tested server is unavailable

  The easiest way to check whether the server is available is to create and run a test with one virtual user in it. In this case, you will be able to check all the responses quickly.

  If the server is running, your firewall settings can block it. So, check them too.

  If the tested server has moved to another URL, you can redirect your tests rather than re-record them anew. See Changing the Tested Server.

• Developers changed the web server’s work logic

  To check whether the server work logic was changed, run a test with one virtual user in it. If the web server is available, but the test fails, this indicates that the server’s work logic has been changed. In this case, please contact the developers to see what differs. Most likely, you will need to re-record your scenario so that your tests can pass.

To get more information on the possible reasons of the failure, examine the Details panel.

LoadComplete waits for the tested server to respond for the period specified by the Receive response timeout option (300 seconds, by default). If LoadComplete does not receive a response from the server within this period, it closes the connection and reports a timeout error.

If a simulated request uses data extracted from a server response, LoadComplete waits for the server to return the needed data for the period that the Request correlation timeout option sets (300 seconds, by default). If LoadComplete does not receive a response from the server within the period, it does not simulate the request and reports a timeout error.

Typical reasons for timeout errors are –

• The server functioned slowly under a massive workload, did not respond to requests in a timely fashion and closed slow connections.

  Web servers use various timeout values for user connections (for instance, IIS 7.5 uses a 120-sec timeout). If the server was not able to respond to a request within this period, it may indicate bad server performance under the load. Contact the developers and inform them about the problem. If they say that the speed is applicable to your number of virtual users, it is worth increasing the timeout values on the server at least for the period of test runs. That will let the tests pass.

• The server closed the connection and LoadComplete failed to simulate the needed request in the scenario, because the connection did not exist. To check whether the connection was closed, select the error message in the test log and view the Response Header panel. If the server has closed the connection, the Connection field will contain “close” in the header.

  

  Click the image to enlarge it.

  Why the server closes the connection depends on the situation that occurred during the testing and on specifics of server functioning. Most likely, the server breaks the connection if it receives some invalid parameters in a request (it is possible, for instance, if you parameterize the simulated traffic and submit invalid data).

To avoid the problem, you can also increase the timeout value. However, we do not recommend that you do this. The timeout is long enough by default, and most likely, the tested web site has performance problems. We recommend that you inform the developers about the problem.

If LoadComplete reports that the connection was closed or was simulated partially and there is no timeout information, this means that either the server or LoadComplete closed the connection. The cause depends on the load policy you used for your test:

• If you simulate a continuous load, these errors are expected (especially, at the end of the test run) as this type of load implies that LoadComplete stops virtual user simulation by time.

  In this case, connections with the Connection was closed and Connection was simulated partially errors are marked as successful ().

• If you do not use a continuous load, these errors indicate that the server closed the connection because the simulated requests contained some invalid data.

  In this case, the connections with the the connections with the Connection was closed and Connection was simulated partially errors are marked as failed (). Explore the request and response contents in test log to find out what causes the situation. Explore the request and response contents in test log to find out what causes the situation.

  Pay attention to the Response Body panel that contains the contents of the server response. Depending on the application type you are testing, the server can place the error description into the response body.

  In addition, pay attention to requests to which the server returns the 500 Internal Server Error, 503 Service Unavailable and other 5xx codes. Usually, these codes mean that the server was not able to process a request (and closed it). To resolve the problem, contact the server administrator or developers and review the server logs to get a clue.

LoadComplete logs this error if it loses the connection to the tested server during the test run. Typically, this happens because the network software is unable to handle massive network traffic and drops connections to the server. That software can reside on the server or client, or on network routers. To work around the issue, we recommend tuning the software settings to let it handle huge traffic successfully. Below are some examples and recommendations.

On the Server Side

On Network Equipment

On the Client Side

The error does not occur if I use another load testing tool ...

LoadComplete reports this error if you have a data selector defined for a response in your recorded scenario and the data selector failed to extract the needed data.

This can happen due to the following reasons:

• A server response does not contain the expected data.

  To check whether the response contains the needed data:

  1. In the Details panel, select the request for which the tested web server returns the problematic response.

  2. Examine the Response Header and Response Body panels. They contains the contents of the server response.

• The data selector works incorrectly.

  To check whether the data selector extracts the correct data:

  1. In the Details panel, double-click the problematic request or WebSocket message. LoadComplete will open it in the Scenario editor.

  2. Open the Response page (for HTTP traffic) or the WebSocket page (for WebSocket traffic) and switch to the Data Selectors tab.

  3. In the list of data selectors defined for the server response, find the problematic data selector.

  4. Make sure the data selector defines the correct regular expression. To learn how to do this, see How to Determine What Data a Selector Extracts.

LoadComplete reports this error when it simulates a request that uses data it extracts from a server response and a timeout occurs while waiting for the needed response.

This can happen, because the tested web server worked slowly and did not generate the needed data before the period, which is specified by the Request correlation timeout option, had elapsed. This may indicate the bad server performance. We recommend that you contact the server developers and inform them about the problem.

If a test passes for one or several virtual users, but fails for a greater number of virtual users, this may mean that the server is protected against denial of service (DoS) attacks. The host’s proxy server or router may include delayed binding and rate limiting capabilities that may treat requests from numerous virtual users as a DoS attack and forcibly close the corresponding connections.  A typical symptom of such an issue is that the last response from the server does not contain the Connection: Close directive.

If you need help with resolving errors, click Ask for Assistance on the Test Engine toolbar at the top of the LoadComplete window. This will open a web page, where you can contact product specialists. If you use LoadComplete Trial, LoadComplete will suggest that you contact a product specialist after scenario verification fails, or if a load test with 25 or fewer virtual users fails.