ASP.NET Secrets, Part 5, Page 4
Can It Cope?—Stress Testing Your Web Apps
It's the new face of that old, often-troublesome Web Application Stress Tool. It's a tool designed to see whether your site can stand up against heavy traffic. It's distributed with the Enterprise and Architect editions of Visual Studio .NET. It's the curiously christened... Application Center Test (ACT).
Here's how it works. You launch ACT and record a browser session, simulating a regular user. You may explore the site, do a little searching, upload a couple of files, whatever users typically do at your site. Then you get tell ACT to rerun that test over and over again, perhaps simultaneously and with great speed. When finished, you check out the results to see how both your server and ASP/ASP.NET applications stood up to being thrashed.
Start by launching ACT: Click Programs > Microsoft Visual Studio .NET > Microsoft Visual Studio .NET Enterprise Features > Microsoft Application Center Test. You'll see a bundle of existing samples. To record your own, right-click the "Tests" node and choose "New Test." Skipping through the wizard, select "Record a new test;" then click the button to "Start recording." An empty Internet Explorer browser window will appear.
Top Tip: Using a dial-up networking connection? It's poorly documented, but ACT won't record test sessions through a regular dial-up. In fact, even if you're recording on the http://localhost/ server whilst a dial-up connection is active in the background, it'll refuse to record. Yes, it's annoyingly picky: Try disconnecting and attempting once more.
Ensure you are not "Working Offline" (if so, uncheck this mode using the File menu); then start acting like a user: browse, log in, search. Play around for a minute or three. When you're done, stop using the browser window and return to ACT, clicking "Stop recording." Provide your test with a name, and then finish the wizard.
Your test should now appear under the list of "Tests." Select it and view the VBScript code generated for you. If you need to remove any unnecessary requests, simply comment out the call SendRequest# line in the Sub Main method at the bottom of your test script.
So, you have your test recorded. Now, let's look at its settings: right-click your test and select Properties. This is where you choose how far to push your application, selecting parameters such as how many simultaneous browser connections you want to simulate or how long you wish to run the test. You also can use the Counters tab to monitor certain parts of your system as the site is being accessed, potentially enabling you to track down bottlenecks. The Users tab also lets you specify a list of test users to log in to your site (however, this requires a little custom programming and a surf through the Help files). Click OK when finished.
When you're ready to begin, add any notes for this test in the top panel; then right-click your test and select Start Test. You'll be shown a summary as the whole thing churns away. If you're curious, you also can click "Show Details" for an instant graphical view of how it's all going.
After the test has finished, you'll probably want a detailed report as to how it all went. Click Close; then select the 'Results' node and highlight your test run. You should be presented with a graphical report showing how well your site handled the situation—or not, as the case may be. Here, you'll be able to see how many application requests per second the Web server was able to handle, how long it took the server to respond, and how much bandwidth you used per second.
If you chose to record Performance Counters, you should also be able to view data about how your machine handled itself, too. If you wish, you can check multiple tests to compare results. More information about analyzing the content in these reports can be found in the ACT help file under "Analyzing the Test Results."
If your site didn't hold up as well as you thought it should—reacting slowly and producing connection errors—you might want to start looking at how you can optimize your application a little more. For example, you may implement caching, rewrite inefficient code, distribute your application over multiple machines (a 'Web farm'), or simply upgrade your server.
No matter what the outcome, it's always good practice to stress test your application, in preparation for the real world. Because you never know when that next flood of visitors will be checking in...
Top Tip: If you have the urge, you can even use ACT directly from within Visual Studio .NET. When creating a new project, select Other Projects > Application Center Test Projects > ACT Project. From here, you can record a test then run it within VS.NET. You don't get the fancy user interface nor the handy samples, plus all the results are reported there and then in the Output window, but it's a potentially useful integration.
Caption: A little test I ran earlier with a bottle-necking application...
Coming up next time, in part one of .NET Data Secrets:
- Generating GUIDs in a Flash
- Making Your Own OLE DB Connection String Creator
- Cheating with SQL
- Finding the Last Identity Number Added
- Seven Steps to a Quick, Editable Windows Grid
See you then!
About the Author
Karl Moore is a technology author living in Yorkshire, England. He runs his own consultancy group, White Cliff Computing Ltd, and is author of two best-selling books exposing the secrets behind Visual Basic .NET. When he's not writing for magazines, speaking at conferences, or making embarrassing mistakes on live radio, Karl enjoys a complete lack of a social life. Check out Karl's newest book, Ultimate VB .NET and ASP.NET Code Book.
# # #