This series

Introduction

It is a good idea to load test your web site before taking it live, to make sure it won't break or perform poorly under load. Fairly recently, a new load tester called StresStimulus was introduced. It is affordable and has some unique features that make it well suited to load test ASP.NET web sites, hence this article to discuss its features. You'll also find a (far from exhaustive) list with other popular load testers, to make it easier to make up your own mind which load tester you want to use.

This article first lists the features of StresStimulus, and then shows how to get started with your first load test. Part 2 goes into more advanced topics such as parameterization.

Lets you set warm up time, to allow web site caches to fill before testing starts.

Keeps track of performance counters (Pro versions only).

Able to save test cases to file (Pro versions only).

Limitations

Because of its tight integration with Fiddler, StresStimulus lacks some features available in more complex load testers:

No ability to mix different scenarios in the same test case (browsing, purchasing, searching, etc.)

You can't have multiple load generating machines controlled by a single controller. Obviously you can run StresStimulus on multiple computers at the same time, but you would have to coordinate them manually.

No easy way to compare test runs, for example of different versions of your site.

Load testing basics

Before creating your first load test, let's do a quick overview of Fiddler and StresStimulus.

One of the challenges in developing web sites is that they get used by many users at the same time. Unfortunately, when you're testing your site, there is only one user - you. Your site may be fine with just one or a few users, but break or perform badly with dozens or hundreds of users. You want to find out about any problems before you go live, not after you go live.

How do you get lots of users to hit your new site before it even has gone live? You could ask co-workers or friends to hit your site, but that requires a lot of effort. Much easier to use a program such as StresStimulus that unleashes dozens or hundreds (or thousands) of virtual users hitting the new version of your site. Additionally, you need to tell those virtual users which pages to visit. And if you have forms on your site, you need to tell them what values to fill in those forms.

Here is how Fiddler and StresStimulus allow you to make this happen:

When you run Fiddler, all requests you send from your browser to a web site and all responses back to your browser are recorded by Fiddler. A request might be simply asking for a web page, or sending values you entered into a form to the web site.

Each request/response pair is called a session. When you run Fiddler, they turn up one by one in the left hand pane in Fiddler.

This means you can record sessions by simply visiting pages in your site yourself with your browser, and by submitting forms to the site.

You can then select one or more sessions within Fiddler and tell StresStimulus to make those into a test case. This tells the virtual users what pages to request and what form values to send.

You'll probably want each virtual user to go through the test case more than once. So in addition to setting the number of virtual users, you can also set the number of iterations - that is, the number of times you want the test case to be repeated.

To make the test more realistic, you can have StresStimulus use new form values for each iteration using the parameterization feature, set think times, etc. You can see how well your site performed by looking at the test results.

Creating a simple load test

To create your first load test:

If you have been using the test site in the download, there is an Open trace log link on the bottom of the page. Click that to see a trace of all traffic to the site, both yours and that generated by StresStimulus.

First close all web sites you have open, so they don't interfere when you record your first session.

Run Fiddler.

To toggle between the free version and the Pro evaluation version, open the StresStimulus menu in the top left of the Fiddler window and click Use free edition or Use Pro Edition.

Run the test site in the download with this article. Or run your own site. You can run the site locally, from within Visual Studio if you want. Press some buttons to generate page loads.

If you now switch back to Fiddler, you will see that the requests you generated and their responses now show up in the left hand pane..

Click the Inspectors tab in the right hand pane, and then click one of the sessions in the left hand pane. This shows the headers and content of the request and its response.

Select the requests to play back:

Click the StresStimulus tab.

In the left hand pane, click those requests you want to play back while holding down the Ctrl button.

Click the dropdown arrow on the Set Test Case button and select Set Test Case with Selected sessions. Option Set Test Case with All sessions would simply select all sessions in the left hand pane.

Now play back the selected requests once by clicking the Run Test Case Once button. You'll see the requests generated by StresStimulus appear in the left hand pane.

In the top left of the Fiddler window, open the StresStimulus menu and click Save Test to save your test settings (Pro versions only).

Increasing the load

Playing back a test case once doesn't really qualify as a load test. Let's increase the number of times the test case is executed. While at it, we'll increase the number of virtual users as well:

Debug tests are just load tests except that they show generated sessions during the test. When the rest of this article refers to load tests, it refers to debug tests as well.

Expand the Test Configuration tree and click Load Pattern.

Select Constant Load and set Number of Virtual Users to 10. This gives you 10 virtual users sending requests to your site.

With the Test Configuration tree still expanded, click Test Duration.

Set Test completion criteria to Number of Iterations and set the number of iterations to 20.

Click the Start Test button to start the load test.

If you're using the test site that came in the download with this article, and you still have the trace page open, you can see the requests and responses as they happen by refreshing the page.

You can also see the requests generated by StresStimulus in the Fiddler window itself, but to do this, you have to run a debug test instead of a load test. After the previous test has finished, click the drop down button on the Start Test button and select Debug Test. Then click the button to start the test again:

After a load test or debug test has completed, you can get rid of all the requests in the left hand pane except for the ones making up your load test by clicking the Reset button.

Test results

Graphs while a test is running

As soon as you start a load test, StresStimulus switches to the graphs pane, showing graphs of requests per second, average response times, etc.

A second set of graphs in the same pane shows the values of performance counters, such as % Processor Time (Pro versions only). StresStimulus allows you to add performance counters to this graph (how).

After the load test has finished, the graphs stay in place until you run another test. To navigate back to the graphs, expand Test Results and click Graphs.

Detailed reports

After the load test has finished, more detailed reports become available. These are accessible by clicking options under Test Results:

Test Summary - detailed summary of how well your site performed, and details of the load test itself (duration, number of virtual users, etc.)

Page Details (Pro versions only) - details on how well each individual .aspx page performed, such as minimum, maximum, and average response times.

Request Details (Pro versions only) - shows details for all requested files, rather than only the .aspx files. Not as detailed as Page Details. Shows how quickly your site serves up images, etc.

Saving test results to a file

There are two ways to save test results to a file. Firstly, by clicking Test Results and then clicking the Create Report button (Pro version only). This gives you an HTML file you can open in your browser.

Secondly, you can simply copy and paste the results to a file. The Test Summary view can be copied into a text file - just select the text with your mouse and copy and paste. The grids in the Graphs, Page Details, Request Details, and Iteration Details views can be copied to a spreadsheet. If you don't have Microsoft Excel, try the spreadsheet in the free Open Office suite.

Requests generated by StresStimulus

During a load test (as opposed to a debug test), StresStimulus doesn't show the generated requests in the left hand pane for performance reasons - there could be many thousands. To see them in the left hand pane after a load test has finished, click the drop down on the Results button:

Errors and Timeouts - requests where things went wrong.

Primary Requests - only requests for .aspx files, not for images, etc.

One issue here is that when you run a normal load test (as opposed to a debug test), StresStimulus doesn't store details for the generated requests beyond the fact that they actually happened. That makes sense, given the space required by possibly tens of thousands of generated requests. But it doesn't help much when you want to know the contents or headers of the requests and their responses from the server.

You can overcome this by running a Debug Test (how). This stores the details of all generated requests and their responses. This allows you to inspect the contents, headers, etc., of all generated requests and their responses (how).

Part 2 of this series goes into more advanced features of StresStimulus, such as NTLM authorization and parameterization.

Share

About the Author

Matt has over 9 years .NET and SQL Server development experience. Before getting into .Net, he worked on a number of systems, ranging from the largest ATM network in The Netherlands to embedded software in advanced Wide Area Networks and the largest ticketing web site in Australia. He has lived and worked in Australia, The Netherlands, Slovakia and Thailand.

He is the author of the book ASP.NET Performance Secrets (www.amazon.com/ASP-NET-Site-Performance-Secrets-Perdeck/dp/1849690685) in which he shows in clear and practical terms how to quickly find the biggest bottlenecks holding back the performance of your web site, and how to then remove those bottlenecks. The book deals with all environments affecting a web site - the web server, the database server and the browser.

Matt currently lives in Sydney, Australia. He recently worked at Readify and the global professional services company PwC. He now works at SP Health, a global provider of weight loss web sites such at CSIRO's TotalWellBeingDiet.com and BiggestLoserClub.com.