WinInet issue: replay slower much than IE opening manually
I have a Web SSL script recorded with winInet level.
When I replay it from a remote http client, I found the time take longer much than I manually open IE vis HTTPS.
But When I replay it from a server which is in same city of the web server, the running speed is similar with open IE manually.
Can anyone know why?
No cookie and extra in the script and log is turn off.
HTTP clients and web server are in same domain.
Thanks in advance.
Could you clarify what exactly do you mean by "remote client"? Are you talking about a cloud-based LoadGenerator?
In general, please describe the two cases (one, in which the replay is of the expected speed and one, in which it's too slow) in LoadRunner terms (Controller, LG, VuGen, whatever is involved).
Only Vugen 11.03 is used.
HTML/http script with SSL was recorded with windInet level. And replay with winInet enabled too.
When the http clients are from differnt country with web server, the resposne time is much slower than operation manual.
For example, web server is in denmark. http clients are from USA.
The response time form USA is quite slow, much slower than manual operation in USA.
(56 sec for script running, 15 sec for manual operation)
The response time from Denmark is OK, similar resposne time as manual operation in Denmark.
(5 sec fro script running, 3.x sec for manual operation)
We disable winInet replay and add web_set_socket_option("SSL_version","TSL"), the performance improved much.
The response time in USA reduced from 56sec to 24sec, but still slower than manual operation.
I am pretty sure , the winInet replay can not measure accurrately the performance .
The question is turn to "how to optimize the script with socket level replay, make the performance is close to the real user operation".
I'll appreciate much for any idea.
Just to clarify the WinInet option only affects replay and doesn't affect recording.
But anyway, it sounds a lot like an SSL handshake or proxy problem.
I would suggest running wireshark (with only the initial HTTPS request in the script to avoid noise) and seeing what traffic is being sent/received. You won't be able to read what's happening, but you might be able to see if things are either transmitting slowly, there are huge gaps in time, or the same data is being sent over and over.
If possible try the application with SSL turned off to see if that makes a difference in response times. You can at least then eliminate SSL as a problem.
I would also try playing around the the proxy settings. If the same script with the same configuration is experiencing different response times in different locations then the problem is likely your environment configuration or infrastructure.