Loadruner error: a solution for Step download timeout (120 seconds)

A netizen asked me one of the following questions:
Loadruner error: Error-27728: Step download timeout (120 seconds)
The syntax check is successful, but an error action is returned when a query is executed concurrently. C (16): Error-27728: Step download timeout (120 seconds) has expired when downloading non-resource (s). How can I solve this problem? I use web_set_timeout, it seems that it does not work. You can directly set the timeout time to 600 in option. (The unit should be second.) It still does not work. The results are still prompted (120 seconds ), it is determined by 120 seconds. When lrs_set_recv_timeout is used, the syntax check does not exist.

Steps:
Set the timeout time to 600 seconds.

Later, I set a winlnet replay instead of sockets option in the advaced region of Internet protocol-preferences in the runt time setting. The option is successfully played back.

Kernzhang is explained as follows (thanks to kernzhang ):

This question is very interesting! Haha! First, LR uses Microsoft wininet DLL to record web protocols! However, when control is running, it simulates requests through socket by default, because these can actually simulate bandwidth, and Microsoft wininet DLL uses this DLL to access the NIC to simulate bandwidth, the simulation is not very accurate! It does not support UNIX applications, but sometimes it cannot process some winnet DLL requests. I think it is a bug. For example, it checks Content-Length during playback, however, when the webpage supports receive more data, the socket simulation will wait until timeout!

I first introduced some advantages and disadvantages and finally returned to this question! This problem is analyzed in two aspects:
First, you need to understand the applicability of the web_set_timeout () function! For example, a web_submit_data () actually contains 10 requests to the server. This function is for the total time of 10 requests! (Do not make a low-level error. The timeout consists of connect, receive, and download :))
Second, I explained some of the above bugs!
Wininet dll can process requests asynchronously in the new version, that is, it is no longer the connection waiting and timeout mode! However, LR uses a socket for Synchronous requests! It will only exit after timeout! Microsoft has explicitly stated that internet_option_receive_timeout is no longer applicable to Microsoft Internet Explorer 5.0. Obviously, they process requests asynchronously! Haha! This is probably a complete explanation of your problem! Haha

Here, I add the following:
Socket-based replay for vugen is a lightweight engine that is scalable for load testing. It is accurate when the thread is used. The socket-based engine does not support socks proxy servers. If recording is performed in such an environment, the wininet replay engine should be used.