Stress-Test Your Web Apps

Make sure your Web apps can hold up under pressure with the Microsoft Application Center Test.


LANGUAGES: All .NET Languages

TECHNOLOGIES: Application Center Test


Stress-Test Your Web Apps

Make sure your Web apps can hold up under pressure with the Microsoft Application Center Test.


By Ken McNamee


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 within Visual Studio .NET Enterprise Architect and Enterprise Developer editions. ACT's purpose is to stress-test your Web application 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 stress-testing your Web application code 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:


  • It's significantly easier to create and use testing scenarios.
  • It now can include dynamically generated Request variables.
  • It lets you use VBScript to define the test's parameters and execution flow.
  • The object model is accessible via any COM client, or .NET client via COM Interop.
  • It's integrated tightly with Visual Studio .NET.
  • It can generate and save a large amount of test information.
  • It creates graphs of the test results automatically.
  • It supports HTTP requests using the SSL protocol (although not when using the browser recording feature).


Creating a 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 " +



    Set oRequest = Test.CreateRequest

    oRequest.Path = "/Default.aspx"

    oRequest.Verb = "GET"

    oRequest.HTTPVersion = "HTTP/1.0"

    set oHeaders = oRequest.Headers


    oHeaders.Add "Accept", "image/gif, image/x-xbitmap,

         image/jpeg, image/pjpeg, application/,

         application/, 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"


      strStatusCode = oResponse.ResultCode

    End If


  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 create and run a test directly from within Visual Studio .NET. 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 VS .NET. 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:


  • Test duration, including warm-up time to give your application a chance to compile and cache pages
  • Whether to use randomly generated users or user information you have predefined
  • Any performance counters you would like to track
  • The number of concurrent browser connections you would like to simulate


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 the 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. 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,, to 100 percent ASP.NET with C#. E-mail him at mailto:[email protected].


Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.




Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.