Load Test Your ASP Application

From Mynoteswiki.com

I Can't Stress It Enough -- Load Test Your ASP Application

J.D. Meier

September 27, 1999

Contents

[edit]

Summary

The following article previously appeared in the MSDN Online Voices "Servin' It Up" column.


[edit]

Introduction

As we migrate from traditional client-server applications to the ever-so-popular Web space, we find ourselves trying to keep up with increasing demands for scalability and performance. One of the biggest challenges then becomes determining how many users your application can support. How do you meet this challenge? A good start is setting clear performance goals and using a Web stress tool.

This article serves as both an introduction to stress testing Active Server Pages (ASP) applications as well as an introduction to Microsoft's Web Application Stress test Tool. In the following paragraphs, you'll learn the basics of stress testing as well as some tips and tricks to run more effective tests and to modify your application based on the results of your tests.

[edit]

The Scenario

You are rolling out an ASP application to an anticipated user base of 1,000 users. You know that the application can handle at least two simultaneous users, because you and your buddy can hammer your application all day without any performance degradation. You wonder whether two users accurately represent how your application will behave under load. While you can always use the standard performance test (release your app and hope for the best), you decide to determine ahead of time how your application will scale. Good career move!

[edit]

Determining Requirements for Testing

To properly stress your ASP application, you need first to determine what load your application is up against. For simplicity, load can be broken down into the following numbers:

  • User base. (What is the total number of users for this application? Usually this number is captured in either unique hits per day, per week, or month -- which you can perhaps break down into a more manageable number, such as unique, hits per hour.)
  • Total concurrent users. (What’s the worst-case scenario at peak time? Plan for it. Hoping works as well as using the Force.)
  • Peak request rate. (How many ASP pages need to be served per second? This is perhaps the most important factor when gauging an ASP application's ability to respond to its users.)

Determining the total number of users and concurrent users for your application tends to be difficult to do before your application is actually in use. This is especially true of Internet applications. Even intranet applications tend to face "user creep," so accurately predicting usage can be difficult. When you don’t know where to start, begin with the basics:

Internet considerations:

  • Break down your existing Internet Information Server (IIS) logs. The numbers may indicate realistic probabilities.
  • How popular is your site really going to be? Popular sites can see as many as 1 million or more hits a day. Not going to be that popular? Then why not "what if" for various scenarios? What if you had a user base of 1000? Or 10,000? Can you solve your scalability problem by throwing more hardware at the problem, or will your application architecture hold you back?
  • What’s the worst-case scenario? Just ask your friends whether worst cases happen.

Intranet considerations:

  • Again, break down your existing IIS logs.
  • Is this ASP app for everyone? How many machines are on the corporate intranet? Can your sys admins tell you anything about peak network traffic?
  • Does that app have a finite intended audience? Just HR? How many HR employees?
  • What's the worst-case scenario?

If you can’t determine the probable load ahead of time, then determining your application's upper limits may be your best bet. How many ASP requests per seconds can you serve if hit by 10 users? 100? 1,000? 10,000? Record your benchmarks. When your traffic logs from actual usage show that you are approaching your limits, you'll not only be glad you know what the current limits are, but you'll have had time to prepare a solution.

[edit]

Presenting the Web Application Stress Tool

While there are a number of stress tools to choose from, for this article, I'll focus on the Web Application Stress Tool (formerly known as Homer), which is currently Microsoft's standard Web stressing tool. If you are already familiar with WebCat, you will appreciate the Web Application Stess Tool's ability to import existing WebCat scripts. If you have worked with InetMonitor, you will appreciate that the Web Application Stress Tool is also GUI based (which is a big plus for many users over the command-line WebCat). Another bonus is it's free, and as a good friend of mine always said, "If it's free, it's for me." In addition to its attractive price, this tool features a fairly complete range of features and is continuing to evolve. Microsoft.com is using it extensively, so they will understand the importance of this tool.

Don't take my word for it, though. Try it out for yourself. I'm providing a list at the end of the article of some third-party stress tools, so you can draw your own conclusions. The bottom line is that you need a tool to put your ASP applications under load so you can tweak your application prior to release.


[edit]

Getting Started with the Web Application Stress Tool

I'll walk you through testing an ASP page with the tool for the first time. I'll also cover using authentication and testing for multiple users, because these issues seem to throw people for a loop when they are first figuring out the Web Application Stress Tool.

To get started, the first step is to download and install the Web Application Stress Tool. You can obtain the latest version of the tool from http://webtool.rte.microsoft.com/ . There is also a tutorial on the site that you may want to go back and visit.

Here are a few points about installation to keep in mind:

  • Do not install Web Application Stress Tool on your Web server. Install it on a separate machine to ensure more accurate test results.
  • ActiveX Data Objects (ADO) version 2.1 or later is required on the machine running Web Application Stress Tool. ADO will be installed by the Web Application Stress Tool installer if the oledb32.dll is not version 2.10.3711 or higher.
  • After installation, you will have a complete installation log, which can be found by default in \Program Files\Microsoft Web Application Stress Tool\INSTALL.LOG.
  • If you have installed previous versions of the Web Application Stress Tool, upgrades will leave the data files intact. Web Application Stress Tool uses Access .mdb files as its data store. The original .mdb packaged with Web Application Stress Tool is WAS.mdb, which can be found in the application’s installation directory.
  • Web Application Stress Tool stores information under the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WAS.

Before launching our newly installed Web Application Stress Tool, we’re going to create a simple ASP script to test the plumbing. Create a new ASP page called MyASPPage.asp and insert the script below:

MyASPPage.asp 

<%@ Language=VBScript %>
<HTML>
<BODY>
<%   CONST ForAppending = 8
  set oFSO = server.CreateObject("Scripting.FileSystemObject")
  ‘translate our virtual directory into a physical path
  strFilePath = Server.MapPath(Request.ServerVariables("PATH_INFO"))
  ‘grab the root of the virtual directory
  strFilePath = left(strFilePath, (InstrRev(strFilePath, "\")))
  strFilePath = strFilePath & "MyFile.txt"
  ‘write out to the screen the full file path
  Response.Write(strFilePath & "
")
  set oTS = oFSO.OpenTextFile(strFilePath,ForAppending, true)
  oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
      "Time: " & Cstr(now()))
%>
</BODY>
</HTML>

This script will write out text file inserting the SessionId and time of activity, which will give us simple validation that our ASP page is executing correctly. Once you are familiar with the tool, you can point to your real ASP pages for actual testing.

Drop the ASP page into a directory on your Web server that allows anonymous access. We’ll cover authentication later in the article, but for now we want to run a basic test. Browse to your new Web page using the full URL, including your server’s name. For example, a full URL might look something like http://MyServer/MyVirtualDirectory/MyASPPage.asp. After you are able to browse the ASP page successfully (be sure to check for MyFile.txt, which will be written to the physical location of the virtual directory), it’s time to launch the Web Application Stress Tool.

When you first launch the Web Application Stress Tool, the following dialogue box will appear:

Image:Fig1_CreateANewScript.gif

Figure 1. Create a new script

While the other options are tempting, choose Manual for now. In the future, you can also create a new script by either choosing Scripts from the menu bar or clicking the New Script icon on the toolbar.

Welcome to the scripts view. The left-hand pane is a tree-view of your scripts. The right-hand pane is where you will modify your script settings. Once you get a feel for the Web Application Stress Tool, you'll be clicking your way right through options. Until then, we'll take it slowly.

Activate the script view by single-clicking New Script from the tree-view in the left-hand pane. Specify your server's name in the Server text field. In the first Script Item, choose GET as your verb. In the PATH field, enter the URL to your test ASP page starting with the virtual directory. See Figure 2 below.

Image:Fig2_EnterURLInPathField.gif

Figure 2. Enter the URL in the Path field

At this point, you can click the Run Script arrow on the toolbar to execute your script (be sure you have the correct script selected from the left-hand pane). The script should crank away for about a minute before it generates a summary report of the performance.

[edit]

Analyzing the Results

You can view the generated report by clicking on the Reports icon on the toolbar. This will create a new tab (Reports) next to the Script tab. Reports are stored in an outline view. First, check the Result Codes information beneath your report. This will give you a quick heads-up to see whether the test ran into any problems. If you see status codes other than 200, you probably have to investigate a problem. Common problems include authentication and incorrect URLs.

By clicking on Overview beneath a given report, you can see a quick breakdown of the test activity. From an ASP technology standpoint, Request per Second, indicated on the Overview section of the Reports, is one of the key statistics to check. The higher this number, the better. In general, if you weren’t able to determine specific goals based on usage reports and estimations, you want ASP Requests per Second to be 30 or higher for ASP pages that do not hit a database or use components. As expected, hitting a database adds overhead to the application.

While the ASP Request per Second counter is included by default in the Web Application Stress Tool, you may want to add some additional counters. You can add additional counters by clicking Add Counter after clicking the Perf Counters icon beneath your script. A particularly useful counter is ASP Requests Queued. This counter is usually key in identifying a blocking or long-running page or component. Analyzing ASP performance is well covered in the following resources:

  • Tuning Internet Information Server Performance
  • Navigating the Maze of Settings for Web Server Performance Optimization
  • IIS 4 Resource Kit
[edit]

Factors Influencing Performance and Scalability

Server-components, database access, and other factors can dramatically reduce ASP's Request per Second number. Various configuration options will also play a role. I'll highlight some of the most common factors here:

  • If you're accessing a database, are you pooling your connections? For details on pooling, please see Pooling in the Microsoft Data Access Components.
  • Are you using ASP Session variables to store state? Session variables can quickly limit scalability. They require server resources and they also hinder your ability to add more machines seamlessly if you face scaling issues, because Sessions are associated with a specific machine. Stateless is the way to go for maximum scalability. See the following article for alternatives to Session: HowTo: Persisting Values without Session.
  • Do you have any Visual Basic® components stored in Session state? Remove them now. Visual Basic objects in Session cause thread-affinity and defeat the purpose of IIS’s thread-pool. It’s a complex subject, but suffice it to say that the rule of thumb is: Don’t store Single-threaded Apartment (STA) objects in Session. If you need to keep objects in Session, they should be marked "Both," and you need to aggregate the Free-threaded Marshaler. Active Template Library (ATL) can create such beasts.
  • Is your Web application set to run in its own memory space? This is actually recommended for process protection. However, if you need to squeeze out additional performance, running your Web application in process will save you some cross-process marshalling overhead.
  • When Microsoft Transaction Server (MTS) components are involved, there can be a significant difference in performance if the components are running as Server packages versus Library packages. A common recommendation is to set the Web application to run in its own memory space, and then run the MTS components in Library packages.

Want more? Please see the following articles for additional information on performance and scalability factors:

  • 25+ Tips to Improve Performance and Style
  • Server Performance and Scalability Killers
  • Maximizing the Performance of ASP
  • Agility in Server Components
  • Tuning the FMStocks
[edit]

Simulating Multiple Users

I'll briefly cover how to set up the Web Application Stress tool to simulate multiple users. You must do two things: 1. Change the Concurrent Connections option on the Settings panel. 2. Create at least as many users under the script’s Users setting as the number of users you specified in the Concurrent Connections option.

To change the number of concurrent users, click the Settings icon beneath your script in the script tree. For up to 100 users, you can set the Stress Level option directly. To simulate more than 100 users, you must also set the Stress Multiplier. The basic formula is: Users (threads) = Stress Level * Stress Multiplier. To simulate 1,000 users, you might set the Stress Level to 100 and the Stress Multiplier to 10.

You will get a warning if you try to run the script without enough users created under your Users setting. You modify your number of users by clicking the Users icon beneath your script in the script tree. You will see a Default group in the right-hand pane. Double-clicking the Default group exposes your user list. If you are allowing anonymous access, simply enter the number of new users you need and hit Create.

[edit]

Running Tests that Require Authentication

If you are running tests against pages that require authentication, you will need to create the appropriate users and passwords for the Web Application Stress Tool to use during runtime. Again, this is performed from the Users setting. You can first remove the current user list by clicking Remove All. You can then add your users. You also have the option of importing user names and passwords from a text file.

In any case, these users need to be valid accounts, and they need to be able to access the IIS machine. If you are using BASIC authentication, you can quickly test the account from your browser by passing in the credentials. In addition, it can be helpful to write out the value of Request.ServerVariables("AUTH_USER") to your text file as confirmation. Our modified ASP code would then look like this: 

  oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
        "Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))
[edit]

Tips and Tricks for the Web Application Stress Tool

In closing, I'll provide quick tips and tricks, and some food for thought:

  • Adjust the storage of your Web site's log file, because this will grow quickly (see the IIS docs)
  • You can trace Web Application Stress Tool activity for debugging purposes by setting the following DWORD to 1: HKEY_LOCAL_MACHINE\Software\Microsoft\WAS\SessionTrace
  • If your Web Application Stress Tool reports show errors, be sure to check the Event Log, browse to your pages outside the tool, and check the Web server’s log: \WinNT\system32\LogFiles\W3SVCi
  • If your processor utilization goes above 85 percent on your client test machines, you probably need to add more client machines.
  • For more fun, take a look at some of the following topics in the Web Application Stress Tool documentation: Page Groups, Query Strings, Cookies, Web Application Stress Object Model, and Active Server Page Client (this gives you the ability to remotely control test clients over the Web).

Please note that this is an unsupported tool; send questions to webtool@microsoft.com. You can find HOWTO and known issues in the Knowledge Base by clicking Search Knowledge Base on the left frame of the Web Application Stress Tool Web site. You can also program this tool; the object model is available for reference at the same site. Resources For more information, the tutorial on the Web Application Stress Web site is a good place to start. Also, be sure to read the topics in the Getting Started section of the online help that comes with the tool -– specifically, a topic entitled: "Web stress testing overview."

  • WebHammer . A tool by ServerObjects that tests Web applications and server
  • LoadRunner . A load-testing tool by Mercury Interactive that predicts system behavior and performance of Enterprise-level applications
  • Enterprise Monitor . A tool by MediaHouse Software, Inc. that monitors, notifies, and recovers your intranet and internet networks
  • Extreme Soft’s PerfMon . A tool for Microsoft Transaction Server that provides direct monitoring of MTS from Performance Monitor
[edit]

... And that’s a Wrap

Until next time, be young, have fun, and drink Pepsi (or a latte if you're in the Seattle area).

J.D. Meier was born and reared on the U.S. East Coast. Since heeding Horace Greeley's advice, he has worked as a Developer Support engineer specializing in server-side components and Windows DNA applications involving MTS and ASP technology.

Retrieved from "http://www.mynoteswiki.com/wiki/Load_Test_Your_ASP_Application"