If you've ever used Microsoft's free Web Application Stress tool (WAS) or Mercury Interactive's nowhere-close-to-free LoadRunner tool, you will definitely appreciate Application Center Test (ACT), included with Visual Studio .NET Enterprise Architect and Enterprise Developer editions. ACT's purpose is Web application stress testing, which is done by flooding it with HTTP requests defined in a script you either can record or create from scratch. Although the other two tools I mentioned work in a similar manner, the WAS tool has some significant functionality drawbacks, and LoadRunner -- although a good product -- can take a significant bite out of your budget.
The importance of Web application stress testing should be noted. It is not enough for me to tell you of a tool's existence and describe how to use it; I also need to convince you why you would want to use it and under what circumstances. In the case of ACT, you should use it if the performance of your Web application is remotely important to you, either now or in the future. You might ask, "How should I know whether the performance of the application will be important in the future?" The simple answer to that question is you probably won't know. In my experience, however, every time I have thought performance would never be an issue with a function or a page, it has come back to burn me. To be safe, you should always stress-test your code.
Drawing from their experience developing the WAS tool (originally code-named, and sometimes still referred to, as "Homer"), Microsoft developers succeeded in creating a much improved product. Here's a short list of some of ACT's improvements:
Creating a Web application stress testing scenario in ACT can be as simple or as complicated as you are willing or compelled to make it. On the simple side, you can click on New Test and record an Internet Explorer session whereby you step through the pages that need to be tested. ACT records all the information -- including any ViewState information -- for each page request into a VBScript file you can then modify to meet your needs. This is where it can get complicated because ACT has an object model you can program against. Figure 1 provides an example of the auto-generated code ACT produces for only one request.
Sub SendRequest1()
Dim oConnection, oRequest, oResponse, oHeaders
Dim strStatusCode
If fEnableDelays = True then Test.Sleep (0)
Set oConnection =
Test.CreateConnection("localhost", 80, false)
If (oConnection is Nothing) Then
Test.Trace "Error: Unable to create connection to " +
"localhost"
Else
Set oRequest = Test.CreateRequest
oRequest.Path = "/Default.aspx"
oRequest.Verb = "GET"
oRequest.HTTPVersion = "HTTP/1.0"
set oHeaders = oRequest.Headers
oHeaders.RemoveAll
oHeaders.Add "Accept", "image/gif, image/x-xbitmap,
image/jpeg, image/pjpeg, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword,
application/x-gsarcade-launch, */*"
oHeaders.Add "User-Agent", "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)"
'oHeaders.Add "Host", "localhost"
oHeaders.Add "Host", "(automatic)"
oHeaders.Add "Cookie", "(automatic)"
Set oResponse = oConnection.Send(oRequest)
If (oResponse is Nothing) Then
Test.Trace "Error: Failed to receive response for " +
"URL to " + "/Default.aspx"
Else
strStatusCode = oResponse.ResultCode
End If
oConnection.Close
End If
End Sub
Figure 1. Application Center Test (ACT) has a programmable object model that uses VBScript by default -- and optionally JScript -- to record an Internet Explorer browser session.
In addition to using the Application Center Test IDE, you can conduct Web application stress testing directly within Visual Studio. Simply create a new ACT Project and either record an IE session or create the test script yourself using VBScript or JScript. Some of ACT's capabilities, however, are not available within Visual Studio. One example is the dynamic test in which ACT monitors how the Web server is responding and modifies both the order of requests and the request headers being sent to suit the scenario.
Once the request information has been finalized, you will need to edit the properties of the test. Here is a list of some properties you can change:
View the results
Once you've created the test, it's time to run it. ACT creates a thread for each browser client it is simulating and starts flooding the Web server with requests following the script you have defined. You can watch the test in progress as ACT displays a graph showing the number of requests per second and also the number of HTTP, socket, and DNS errors per second. You should see something similar to Figure 2.
Figure 2. While the test is running, ACT displays the test's progress in both requests and errors per second.
Once Web application stress testing test is completed, you are presented with the results screens (see Figure 3). There are too many performance metrics to detail here, but it is important to note that the resolution is at the Request level. Thus, ACT can tell you that a particular page performed badly but it can't tell you which method present within the page is the culprit. That's where ASP.NET's tracing ability can really come in handy.
Figure 3. ACT stores a wide array of performance metrics that should help you pinpoint problem areas.
If the page is a candidate for output caching, you should try to run the test with the Output Caching option first turned off and then again with it turned on. The results usually are pretty amazing. You can use the same technique, however, for any type of change you make to the page. Web application stress testing before and after changes can give you a good idea of whether your code is getting bloated or more efficient as development progresses.
Used in conjunction with ASP.NET's tracing and debugging capabilities, Application Center Test can help you pinpoint any performance problems in your Web application code. In addition, it also can help you with capacity planning as you try to decide how many Web servers you will need to support the anticipated traffic. Using ACT heavily during -- as well as after -- development can give you an idea of how the architectural design is panning out and whether an increase in data and/or HTML caching is necessary to reach your performance goals. This type of information can be absolutely invaluable to the overall success of a Web project.
Ken McNamee is a senior software engineer with RelayHealth Corp., the premier provider of secure, Web-based doctor-patient communication services. Prior to this, he led a team of developers in re-architecting the Home Shopping Network's e-commerce site, HSN.com, to 100 percent ASP.NET with C#. E-mail him at mailto:kenmcnamee@hotmail.com.
This article was provided by asp.netPRO Magazine, an online information resource for the ASP.NET developer community, which helps professional software developers build, deploy and run the next generation of dynamic, distributed Web applications quickly and easily. Click here for subscription information.
This was first published in June 2003