Often times when you perform user load executions in IBM Rational Performance Tester (RPT), you come across various connection errors depending on the schedule design, network issues and so on. Its also interesting to see that sometimes the connection time-out error takes place only for a few of the virtual users as compared to the rest where the execution succeeds without any failure notice.
RPT is a load generation performance testing tool and mimics most of the recorded behavior during playback of the scripts. So overall whatever the connection times, response times, think times and so on are captured during recording is being utilized during playback action.
Considering this fact, the reason for time out behaviors could be many, but mostly related to how the application is responding to the requests during playback as compared to recorded mode. On the other hand RPT does allow you to modify Time-Out behavior of a recorded test. To access this setting:
- Open a recorded HTTP test in RPT.
- On the right hand side under the Test Elements Details heading, select the HTTP Options tab (As seen below).
- There are two settings that affect the Time-out behavior: Timeout action and Timeout.
Timeout action: Indicates what the test should do if the primary request for a page does not succeed within the Timeout interval. If log error and continue execution is selected, the test logs the error and proceeds to the next page. If Try to reload the page is selected, the test attempts to reload the page one more time; if that attempt fails, the test logs an error and proceeds to the next page.
Timeout: Specifies the time threshold for initiating the action that is selected for Timeout action. The test will wait up to this amount of time for a response. If the response comes back before the timeout limit, the test will proceed to the next action immediately when the response is received. The Timeout action and Timeout value settings apply to every page in the test.
That being said, there could be several application behaviors which can also impact the time-out properties of requests/response data. Sometimes, the host application server locks out your IP address, because the server notes that your IP address sends several virtual users.
Let's take another such frequently occurring error. For example:
Error occurred during connection to server 'servername.oscar.local'. Explanation message: 'Connection timed out: no further information'. This secondary request will be skipped.
So what does this indicate? In its literal sense RPT tried to open a connection while trying to execute a request to the server for a secondary request (i.e. not the primary but something like a gif) and RPT was unable to open the connection to the server.
It's probably worth looking at all the previous requests and responses. Use the Protocol viewer where you can see the browser view or the actual response from the server. If there are no errors then the symptoms indicate a problem with the application or server under test.
In addition to this, if the network connectivity and bandwidth between the host controller and its agents are not uniform, then this might cause communication errors.