I have been running performance tests using Visual Studio Web Tests and Load testing. The goal has been to prove the raw load time and the scalability under increasing users. The web test recorder is quite good for simple request-replay. However, beware a bunch of work is required to parse previous requests for keys to be passed back in subsequent requests, especially for more complex web applications but not as much on simple web sites.
Here’s the results for the single user playback with requests grouped into relevant transactions that we needed to measure.
The odd thing that was happening though is that when we were timing the action Open Report with a stopwatch manually in the browser we were getting typically getting under 5 seconds for completion. The reason for the difference became clear when you watch the web test running. You will see each request going sequentially. If you compare it to the timing from the browser, the actually running is not like that. Below is the timings column from network monitoring from the browser. The two highlighted rows are the requests that take the longest amount of time, but are run together.
Adding up these request sequentially gets us to similar total time as to what the web test replay presented. So to make the request parallel in the web test you need to set the requests as dependent requests to the first. Right-click the request and select Add Dependent Request.
This will add http://localhost/. Delete that request after you have drag-and-dropped the requests that you want to run concurrently into the Dependent Requests folder.
Rerunning the web test after this change resulted in timings much like what we experienced manually.
Other things to look for is that Think Times are not on and set to 0 for all requests and turn on cache control for all requests.
Update: So when does the web test recorder get the dependent requests correct? Taking into account the Initiator column in the Network tab of the development tools made it clear:
These link and script tags are by default dependent requests for the page.
That’s very common for Visual Studio family of products – when you get an avalanche of errors, the first one is usually real and the rest are misleading.