ToolKit
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 " +
"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 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, HSN.com, to 100
percent ASP.NET with C#. E-mail him at mailto:kenmcnamee@hotmail.com.
Tell us what you think! Please send any comments about
this article to mailto:feedback@aspnetPRO.com.
Please include the article title and author.