Typical Response Codes

Problem: During simulation, the server may respond in a different manner than it responded during recording, at that, the response still may be interpreted as successful.

A possible cause of responding in a different manner is that the simulated data does not match the data which the server expects to obtain. For instance, you could change the recorded scenario or use variables to set request contents, and the values sent to the server were interpreted by the server as invalid.

Solution: Try the following:

• Add the actual response code to the list of expected codes of the scenario or request. For more information, see Setting Expected Response Codes.

– or –

• Re-record the scenario so that it contains the new response code.

Problem: This is the effect of conditional GET requests. The browser retrieves data from the cache instead of sending requests to the server and receiving responses from it.

Solution: Re-record the scenario using the browser private mode, or clear the browser cache, cookies and temporary files manually and re-record the scenario. If you use Internet Explorer or Firefox, when you start recording, you can command LoadComplete to clear your browser cache automatically. See Managing Cookies.

Problem: The requested resource requires authentication and no credentials were provided or they are incorrect.

Solution: Try any of the following:

• In the Authentication table of your project or in your scenario (depending on the authentication protocol), check the spelling of the specified credentials.

• Check whether the authentication procedure was performed during traffic recording. Probably, you logged in prior to recording.

• If several virtual users are involved, provide individual credentials for each of them. See About Parameterizing Requests.

When an application uses NTLM authentication, the 401 response code is returned twice during the authorization procedure. This is an expected behavior for this type of authorization.

Problem: Your web application requires authentication, and you use the same login information for all of your virtual users.

Solution: Specify different login information for different virtual users. You can do this by binding the request parameters that specify the login and password to variables holding a list of such values. For more information, see About Parameterizing Requests.

Problem: The server has reached the maximal number of connections and does not allow creating new connections. The Connection: close string is returned as the last line of the response header.

Solution: In non-server operating systems, Internet Information Services have a relatively small maximum number of simultaneous TCP/IP connections. To learn how to increase this limit and whether it is possible to do that, refer to the IIS documentation.

Problem: The requested page or resource was not found at the given URL.

Solution: The solution depends on the URL type:

• For top-level URLs (like www.example.com), one possible cause is that the request was directed to a web server that has no requested page or resource. This may happen if DNS entries are fundamentally corrupt, or if the web server has corrupt internal records.

  Another possible cause is that the web server no longer hosts the web site, page or resource and that it does not provide a redirection to another computer which now hosts the site. However, if the site has recently moved, then the 404 message may also be triggered. This is also a DNS issue, because the old web server should no longer be accessed - as soon as global DNS entries are updated, only the new web server should be available.

• For URLs of lower levels (like www.example.com/page09.html), this error can indicate a broken link. You can check this easily by trying the URL in a web browser.

Problem: The connection was terminated from LoadComplete because of a too short Load Testing timeout.

Solution: Increase the value of the Receive response timeout setting of the Simulating - General dialog.

Problem: The connection was forcibly closed by the tested web server (in this case, the Connection: close string is part of the header of the web server’s response which comes last in the problematic connection).

Solution: In a general case, you need to know how the web server works and to analyze the actual traffic sent to the web server to find the difference between the expected and actual requests and responses.

If multiple virtual users participate in a load test, then the server may have reached its peak load and has stopped responding. If possible, increase the timeout setting on the server side. Please refer to the server documentation for instructions on how to do this.

Problem: The web server encountered an error or is unable to perform a request.

Solution: Typically, the explanation of the situation, as well as information about whether it is a temporary or a permanent state, is in the body of the server response. To solve the problem, ask developers to change the application code so that the application saves the response body to some log file, run the test against the changed application and analyze this file.