Thread: [OpenSTA-users] Can a script wait until the end of a HTTP Binary file download completes before con
Brought to you by:
dansut
|
From: Tam W. <tam...@te...> - 2007-05-21 22:42:35
|
Hi, I am using the OpenSTA toolset for testing a Web Proxy rather than a web server. I want to use the tool to generate HTTP load. One of the forms of load on a proxy is http downloads (mostly of binary files). Can the OpenSTA toolset simulate a real world HTTP binary file download? In particular will a VU script wait until the end of the file download before continuing with the next GET request in the script? I have managed to record a script which downloads a word document file, but even though I have tried to use, LOAD RESPONSE_INFO BODY ON 1 INTO MyBody I am fairly suspicious that TestExecuter isn't waiting for the full file download before the VU script finishes, it seems to simply wait until it gets the 200 level response and the first (of many) packets of data. I'm fairly sure I'm not suffering from the issues/bugs in the FAQ to do with the LOAD RESPONSE_INFO BODY call failing (which I worked around by loading the HEADER first), because I get a status of 0 and I can log the first few bytes of the body. Any help gratefully received. Happy to send more detail if I'm not on an impossible path. OpenSTA Version:1.4.3.20 and OS: Windows 2003 Server Tam Willacy=20 Testing Questions Ltd | www.testingquestions.com=20 |
|
From: Dan D. <ddo...@me...> - 2007-05-22 12:36:35
|
Tam Willacy wrote: ================== >Can the OpenSTA toolset simulate a real world HTTP binary file download? >In particular will a VU script wait until the end of the file download >before continuing with the next GET request in the script? >I have managed to record a script which downloads a word document file, >but even though I have tried to use, >LOAD RESPONSE_INFO BODY ON 1 INTO MyBody >I am fairly suspicious that TestExecuter isn't waiting for the full file >download before the VU script finishes, it seems to simply wait until it >gets the 200 level response and the first (of many) packets of data. Tam, you should be able to accomplish this binary download with opensta. If you want to have the behavior be that the next GET after the download waits til the file is downloaded (though not sure why that matters--you can put a Timer around the binary download PRIMARY GET and time the download irrespective of what else happens downstream), try inserting a SYNCHRONIZE ALL after the last GET URI following the PRIMARY GET URI that triggers the download -- this will cause the script to wait until the PRIMARY GET and all subsequent GETS to execute before continuing. ...Dan Dan Downing www.mentora.com |
|
From: Bernie V. <Ber...@iP...> - 2007-05-22 13:10:18
|
> Tam, you should be able to accomplish this binary download with opensta. > If > you want to have the behavior be that the next GET after the download > waits > til the file is downloaded (though not sure why that matters--you can put > a > Timer around the binary download PRIMARY GET and time the download > irrespective of what else happens downstream), try inserting a SYNCHRONIZE > ALL after the last GET URI following the PRIMARY GET URI that triggers the > download -- this will cause the script to wait until the PRIMARY GET and > all > subsequent GETS to execute before continuing. The essense of what Dan said is correct however the proper syntax of the command is 'SYNCHRONIZE REQUESTS'. You don't need to use ''Load response_info' to get OpenSTA to wait until the binary file is downloaded before proceeding with script execution. The only reason you would load response_info body or header is if you wanted to examine the response and keep in mind that with the version of OpenSTA you have, you are limited to looking at the first 64K bytes of the response. The synch command will cause script execution to pause until the entire file is downloaded (not just the first 64K bytes) The following code fragment will do what you want and time the event as well; Start Timer BINARYDOWNLOAD GET URI "http://www.iperformax.com/BernieVelivisResume.pdf HTTP/1.1" ON 1 & HEADER DEFAULT_HEADERS & ,WITH {"Accept: */*", & "Referer: http://www.iperformax.com/about.html", & "Accept-Language: en-us", & "Connection: Keep-Alive"} SYNCHRONIZE REQUESTS End Timer BINARYDOWNLOAD -Bernie Velivis www.iPerformax.com |
|
From: Dan D. <ddo...@me...> - 2007-05-22 13:27:49
|
Bernie Velivis wrote: ========= >The essense of what Dan said is correct however the proper syntax of the >command is 'SYNCHRONIZE REQUESTS'. You don't need to use ''Load >response_info' to get OpenSTA to wait until the binary file is downloaded >before proceeding with script execution. The only reason you would load >response_info body or header is if you wanted to examine the response and >keep in mind that with the version of OpenSTA you have, you are limited to >looking at the first 64K bytes of the response. The synch command will cause >script execution to pause until the entire file is downloaded (not just the >first 64K bytes) > >The following code fragment will do what you want and time the event as >well; > > Start Timer BINARYDOWNLOAD > > GET URI "http://www.iperformax.com/BernieVelivisResume.pdf HTTP/1.1" ON 1 >& > HEADER DEFAULT_HEADERS & > ,WITH {"Accept: */*", & > "Referer: http://www.iperformax.com/about.html", & > "Accept-Language: en-us", & > "Connection: Keep-Alive"} > > SYNCHRONIZE REQUESTS > > > End Timer BINARYDOWNLOAD Bernie, thanks for the catch on the syntax! Think I momentarily confused it with DISCONNECT ALL :) ...Dan Dan Downing www.mentora.com |
|
From: Tam W. <tam...@te...> - 2007-05-23 04:05:23
|
Hello Dan and Bernie and the list, Thank you both for your quick responses. I won't be back on this work until Friday so will investigate more then and report back. =20 The following is further info, but no need to respond to it unless something obvious jumps out to someone. First priority is for me to retry it. It will help a lot knowing that it should work. =20 ---------- I must be doing something different or not understanding something as my code looks very like Bernie's example. And I have tried with and without SYNCHRONIZE REQUESTS and with and without LOAD RESPONSE_INFO. However it is worth me repeating these tests as I was experimenting at the time and might have got something wrong. =20 My file takes at least a few minutes to download manually vi IE (13Mb) but in OpenSTA it is only reported as a few seconds. =20 I tried the LOAD RESPONSE_INFO only because I thought that way I could see how much of the body I was getting. I could only get (log) the first 5 bytes of the file. But the 64Kbytes limitation might mean that I was shooting myself in the foot with that idea. I will try not using the LOAD RESPONSE_INFO. =20 Another idea... Perhaps it is because I have only tried it in the Run in the Test Modeller and the Single Step in the Commander, OR not let the test run for long enough for the full download to occur. I see in the single step log it says something like 'binary body' and implies it won't therefore show it in the log. I will try a full (not single step) test run with code like Bernie's and run it for long enough for the full file download to complete and check what value the timer returns. =20 As you pointed out I don't really need to wait for the GET to finish, I just want a timer value which is the download time (to the last byte of the binary file) and more importantly I want the full body being downloaded through the proxy I am testing (rather than the connection being dropped) so that it experiences all that load. I'll report back on Friday. I appreciate your help. Regards, Tam Bernie Velivis wrote: =3D=3D=3D=3D=3D=3D=3D=3D=3D >The essense of what Dan said is correct ... |
|
From: Tam W. <tam...@te...> - 2007-05-25 09:20:04
|
Hello, Well in the end I found that everything was working correctly for my binary file download. The timer *was* timing the full download and the script does wait for the full download whether I use "SYNCHRONIZE REQUESTS" or "LOAD RESPONSE_INFO BODY". I can see in my proxy log that the full file is downloaded. So thank you to those who affirmed how the script worked. It made a huge difference in working out what was wrong (or not wrong in this case). My main mistake (besides a lack of faith!) was thinking that a 12Mb file would take a substantial time to download when it only takes a few seconds across an internal network. Also, because I was checking using either the Script Modeller or the Single Step I was seeing it respond when it got the 200 level response (after a split second) but not noticing the few seconds delay before the rest of the script finished (when it was downloading the rest of the file). =20 Kudos to those who tirelessly respond to queries on this list. It is a real help. =20 By way of contributing...=20 1. I have a batch file which works around the script caching issue and occasional instability of the toolset which I can tidy up and share. Any interest? I run it on one machine before kicking off a test run. It uses pskill and psexec from www.sysinternals.com to kill all the OpenSTA processes on all machines running OpenSTA, empty out the engine temp directory and then start the processes again. Nothing too flash (the only trick is in setting the common directory in the path on each machine, as mentioned in one of the FAQs). =20 2. Also, I haven't noticed anything on the forums or FAQ about FTP support (other than a review from a few years back). It seems that (with my web proxy at least) I can get FTP to work if I do it via a web proxy, i.e. OpenSTA records it (with a few errors) and played back. E.g. something like (this is from memory not cut and paste), CONNECT TO 1.2.3.4:8080 ON 1 GET URI "ftp://user1:pas...@te.../file1.txt HTTP/1.1" ON 1 & HEADER DEFAULT_HEADERS & ,WITH {"Accept: */*", & "Accept-Language: en-us", & "Connection: Keep-Alive"} ... Thanks again for the help, Tam Tam Willacy Testing Questions Ltd | http://www.testingquestions.com |
|
From: Bernie V. <Ber...@iP...> - 2007-05-23 11:59:53
|
Tam, > My file takes at least a few minutes to download manually vi IE (13Mb) > but in OpenSTA it is only reported as a few seconds. Is there a chance that the file is cached? Check the status returned for the request and see if you are getting a status of 304. If so, the server is not downloading because the request you sent indicates there is no need to download the file since it is cached and current. -Bernie |
|
From: Bernie V. <Ber...@iP...> - 2007-05-23 12:17:15
|
Tam, >I tried the LOAD RESPONSE_INFO only because I thought that way I could >see how much of the body I was getting. I could only get (log) the >first 5 bytes of the file. But the 64Kbytes limitation might mean that I >was shooting myself in the foot with that idea. I will try not using >the LOAD RESPONSE_INFO. The largest string variable in your version of OpenSTA is 64K bytes. If you do a load response_info body into a variable, the entire download completes but the output is truncated to the size of the string variable. Both the load response_info and the synchronize commands cause the script to pause until the request completes. Since you were at one point using both, removing one should have no effect on the pacing of your script. As I wrote before, I suspect the file is not being returned and examining the status of the completed request should tell you why. -Bernie www.iPerformax.com |