Web Performance Test Engine Overview
Understanding how the Web performance test engine works can help you correctly create and configure your Web performance tests.
Understanding the Web Performance Test Engine
A key concept to understand about the Web Performance Test Engine is that Web Performance Tests work at the HTTP layer. Web Performance Tests contain a list of HTTP requests; each of these requests is primarily made up of querystring parameters, form parameters, and a URL that targets a Web server. The Web Performance Test Engine executes these HTTP requests, retrieves the responses from the server or servers, and collects timing data.
Because the Web Performance Test Engine works at the HTTP layer, it does not run client-side scripting like JavaScript or ActiveX controls. Web Performance Tests are concerned with generating load on a server.. Therefore,, client-side scripting that only affects the appearance of a Web page is not significant to the Web Performance Test. Client-side scripting that sets parameter values or results in additional HTTP requests, such as AJAX, does affect the load on the server and might require you to manually modify the Web Performance Test to simulate the scripting.
A common misconception is that because recording occurs in Internet Explorer, and the Web Performance Test Result Viewer displays results in a browser control, Web performance tests must somehow execute using Internet Explorer. This is not the case. All requests are executed directly using the Web Performance Test Engine; no interaction with Internet Explorer or any other browser occurs. The Web Performance Test Engine communicates directly with the target Web server using standard HTTP request/response messages.
Similarly, the embedded Internet Explorer control on the Web Browser tab in the Web Performance Test Viewer only displays response pages received by the Web Performance Test Engine. The Web Performance Test Engine writes the responses to a temporary location on disk and then loads the temporary files in the Internet Explorer control in the Web Performance Test Viewer. This browser control has in the result viewer is configured specifically not to run JavaScript or ActiveX controls. A common source of confusion is when customers are testing pages that host controls, which result in an error being displayed in the browser control in the result viewer. This does not mean the test is not working correctly. You have to examine the response tab to validate the response. Visual Studio 2010 Ultimate adds new extensibility in the result viewer to host custom tabs, which enable custom browsers. Look on codeplex.com/teamtestplugins for new browser controls to display these types of responses.
Another source of confusion is that different browser templates can be selected when you run Web load tests. These browser templates only affect the default set of HTTP headers sent with each request. The key header that Web servers use to determine the browser type is the UserAgent header. The Web Performance Test Engine issues requests directly using standard HTTP protocol regardless of which browser template is selected.
See Also
Concepts
Other Resources
Creating and Editing Web Performance Tests
Examining Web Performance Test Results Using the Web Performance Test Results Viewer
Creating and Using Custom Plug-ins for Load and Web Performance Tests