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.
If you like this article, please vote for it.
Other popular load testers
A simple Google search will give you lots of load testing tools besides StresStimulus. In the table below, you'll find some of the more popular load testers available.
|WCat||Simple and fast load tester. Free, but lacks some basic features, such as support for ViewState. |
|Apache JMeter||Open Source Java based load tester. Steep learning curve.|
|WAPT||Reasonably affordable load tester. Easy to use.|
|Load tester built into Visual Studio 2010 Ultimate||Excellent full featured product, powerful yet easy to use. Very expensive though.|
To run StresStimulus, you need:
- Fiddler 220.127.116.11 or later (free download).
- Windows 2000 to 2008 / XP / Vista / 7, with Microsoft .NET Framework 2.0 or later.
- 5 megabytes of available disk space / 800 MHz processor / 256 megabytes RAM.
StresStimulus comes in these versions:
The rest of this article will make it clear when a particular feature is only available in a Pro version (that is, not in the free version).
- Free version- Allows you to do real load testing. No time limit, use as long as you want. Limited in key areas, including:
- Reduced reporting of test results. Only summary information available. No reporting on performance counters.
- No ability to save or load a test case. Next time you run StresStimulus, you need to recreate your test case.
- Number of virtual users limited to 100.
- Test duration limited to 10 minutes or 999 iterations.
- Reduced think time options.
- Pro evaluation version- All features enabled, but only suitable for very light load testing:
- No time limit - use as long as you want.
- Number of virtual users limited to 10.
- Reduced think time options.
- Pro trial version- 14 day trial with all features enabled.
- Pro paid version - All features enabled. Maximum number of virtual users depends on your license.
- An extension of Fiddler, the popular HTTP debugging proxy.
- Very easy to create simple tests.
- Allows you to record a test case with your browser and then have that test case repeated by multiple virtual users.
- Shows test results in graphs and in text based reports (restricted in free version).
- Supports parameterization, allowing you to load form field values from input files.
- Supports Basic and NTML authentication, allowing simulated users to login to your site using Windows accounts (Pro versions only).
- Simulates thousands of virtual users (capped at 10 in Pro evaluation version, 100 in free version).
- Lets you increase the load in steps, to find the breaking point of your site.
- Virtual users keep track of cookies and hidden fields, such as ViewState.
- Set think times of virtual users.
- Lets you set simulated browser (IE version, Firefox version, Chrome, etc.) and network (LAN, dial-up, etc.)
- 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).
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.
StresStimulus provides these types of 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.
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.
- Iteration Details (Pro versions only) - fairly sparse summary of the iterations executed during the test.
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.
- All Requests - all requests, including those for images, etc.
- User's Iteration - shows a particular iteration by a particular virtual user.
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.