1. Tell your clients/users that the application failed to respond in the 120 secs time frame

Well, straight-forward. This is because it failed the 120 secs benchmark, an equivalent of 2 mins. Imagine a normal application not responding within 2 minutes is serious where we are anticipating an average respond time of 10 secs!. However, take note that if your application can respond more than 120 sec, then consider the next suggestion.

(Source: Jakob Nielsen, Response Times: The Three Important Limits)

2. Set the Step Download Timeout to 999 secs

This was brought out in the LoadRunner Yahoo Group. Why 999 secs? The benefit of doing this is that you are able to determine the response time from the application in the 999 seconds limit without allowing it to fail. This is good when you want to measure the actual timing without defining a benchmark.

3. Limit the Step Download Timeout to the expected response time

For this, discuss with your clients/users about the requirements for expected response time. Once you gotten the information, configure the Step Download Timeout accordingly to the expected response time. In this way, you are able to tell if the application pass or fail immediately against the expected response time. But if your clients/users wants to know the actual time taken, then it would be advisable to follow the suggestion in point [2].

Hope this will help you have a better understanding on the impact when you configured the Step Download Timeout and assist you in your followup actions.

Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s) [MsgId: MERR-27728]

Step Download Timeout means that the step needed to performed for the subsequent step to be performed have reached its timeout limit (default is 120 secs) in LoadRunner. A more detailed explanation can be found in Document ID 15370 – Error: “-27751: Step download timeout (120 seconds) has expired when downloading resource(s)…” even though timeout is set.

Having mentioned the above, there are situations we must take note when this error occur. If the error occurs during the generation of the script (replay in Vugen), it could mean that the application is really taking time of more than 120 secs to complete the download of the resources. You may want to configure the timing to suit your application needs.

If the error occurs during a scenario execution and happens in the middle of the scenario (usually with a large amount of load), the application is handling a lot of load and unable to attend to all the vuser request, thus (maybe) taking more than the configured download timing. For this,it will be better advisable to look at the system utilization of the server to seeth out any performance problems.

To determine the initial problem, we can ask the following questions, that is similar to a previous article, “Why are my scripts/vusers failing?“.

1. Does the error occur in Vugen?
2. Does the error occur in Controller?
3. If yes for (2), does it occur in the start of the scenario run or in the middle of the scenario run?
4. If yes for (2), what is the amount of running users when the error occur?

The above, can scope down to the area of problem and allow you to determine your next course of action.

If you have decided that the Step Download Timeout needs to be configured, you can configure that in the Runtime Settings of the script. There are other articles that you may find useful should you required to configure the Step Download Timeout:

Document ID 11299 – How to increase the connect , receive and step timeout value for Web Vusers
Document ID 15450 – How to increase the timeout settings in a Web script
Document ID 22864 – How to resubmit a Web request if “Page downloads timeout” is received

To access the above articles, please ensure that you have a valid user login into the Support Website.

Final note, its best to determine the characteristics of your application before applying the configuration. (Do not configure to suit the load test but rather let the load test determine the configuration).