This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

MIND


This article assumes you're familiar with IIS.

Stress Testing Your Web Site
Sara Rea
     
Can your Web applications cope with hundreds of users all at once? The Microsoft InetLoad utility can help you discover the answer.
The corporate Web application that you've spent many hours lovingly crafting is about to go live. You're running on Internet Information Server (IIS) using Active Server Pages and Active Data Objects to manipulate SQL Server™ data. Several hundred users will use your app concurrently at peak times. Since your application is truly scalable, deployment should be no big deal. Or will it be? Are you sure you want to find out whether it's scalable after you go live?
      Maybe it would be a better idea to stress test your application first. Then you can determine whether you have an application truly worthy of the "scalable" label. Let's explore how you can use a Microsoft® utility called InetLoad to measure the performance of a Web application when it's being bombarded with hits from all sides. My sample Web page will be an ASP-designed site that uses VBScript to execute server-side code.
      InetLoad is a free utility that helps you stress test your applications by simulating simultaneous access by thousands of Internet users. Unlike most similar tools, it supports a number of popular Internet protocols and authentication methods. It can also be customized in several ways. I'll be using InetLoad to test pages against the HTTP protocol.
      To begin, you need to download and install InetLoad. Go to http://www.microsoft.com/downloads/search.asp? and look under the Internet Development Tools & SDKs section for Inetload 2.0. (Note: InetLoad only runs on Windows NT® version 4.0 and should be executed from a machine other than the one where IIS is running.) Make sure you take time to read the Inetload.doc file. InetLoad is customizable; Figure 1 lists the relevant information you will need to supply InetLoad when you run it.

Preparing a Test
      Once InetLoad is installed, you will need to prepare your pages for testing. It probably will not be necessary to stress test all Web pages for your application, just the ones that you know will be hit often or contain the most intensive server-side scripting. If a page contains just plain-vanilla HTML without extra processing, it will not be necessary to stress test it. Keep in mind that in order for the test to work, no security restrictions can be present on the target IIS virtual directory.
      Some of your pages may have parameters passed to them by other pages. In such cases, you will need to modify the page so that these parameters are hardcoded. Figure 2 contains the sample ASP page to be tested. Make sure the database you are accessing is fully populated with applicable data. You want database access to be as representative of the actual environment as possible.
      The next step will be to define configuration options from within InetLoad. Figure 3 demonstrates options chosen to simulate 60 concurrent users operating on 50 worker threads with a 30-millisecond delay between each page request. The Command script field has been filled with the name of a text file. This file contains the following, where TestDirectory is the name of a valid Virtual Directory on your IIS server and SampleTestPage.asp is the name of the Web page being simulated: 


 GET <FIXED>url:/TestDirectory/SampleTestPage.asp
Your configuration can be saved by choosing File | Save As and specifying the name of an .ini file. Refer to the FAQ section of the Inetload.doc file if you get an error trying to execute InetLoad.
      You will need to have Performance Monitor executing on the host IIS machine while the test is being performed. This will be useful in identifying any resource bottlenecks. Several counters can be loaded, but make sure you load Processor%, Requests Failed, Requests/Sec, Total Queue Length, Current Connections, and Requests Current. It will be helpful if someone executes your test page from within a browser while the test is being performed. This will enable you to determine whether your stressed page will end up stressing your user.

Analyzing the Test Results
      It may be necessary to repeat the test with different numbers of users. This way you can determine at what point (if any) your Web page fails to be scalable. You may need to change your page so that more concurrent users can successfully access your pages.
      Upon successful completion of your test, you will want to analyze several factors to determine if your page is acceptable. Performance Monitor should indicate whether the server was able to handle the pressure gracefully (see Figure 4 ). An important thing to note is the average CPU utilization. An average of under 70 percent is a desirable target. You will also want to note the way IIS handles the page requests. They may queue up at first and then level out as the test continues. It can be useful to determine the number of transactions per second. You will want to evaluate the results based on what will ultimately be expected of this application.
       Another thing to analyze is the log file. This allows you to evaluate the latency of every page request. It will also tell you if an error was encountered and what that error was. A different log file will be created for each test. In these lines from a successful stress test 


 1998/03/11 10:02:46,ltcy,clnt32,cmd Server Connection,resp Connected successfully
 1998/03/11 10:02:48,ltcy3778,clnt1,cmd GET/TestDirectory/SampleTestPage.asp,resp HTTP/1.0 200 OK
the first line indicates that a single-user connection was established. The second line indicates that the page request was made successfully. In the event of an error, a grumpy message with a different HTTP return code would be displayed in the place of "OK."
      Within InetLoad, you will be able to note whether any dead user sessions, error returns, or connection failures were encountered. If these indicators start to accumulate from the very beginning of the test, you'll know you have a problem that needs to be addressed.
      The most important indicator will be how the page responds when someone is accessing it from a browser as the test is being performed. If the page does not return within a reasonable period of time for your user, you may want to consider streamlining your page.

Conclusion
      As the need for rapid development continues to grow, it is important that testing is not neglected. The Internet opens up your applications to many more potential users than traditional client-server applications. Therefore, it is even more important that stress testing be a fundamental part of your testing regime. InetLoad is an excellent tool for easily and accurately measuring your applications potential. More functionality is available within InetLoad than I have space to explain here. Take the time to download and utilize this new tool from Microsoft.

From the June 1998 issue of Microsoft Interactive Developer.