Load test for your ASP program

Program

J.D Meier.

September 27, 1999

Content
Introduced
Plot
Test requirements
Introducing the Test tool was
Analyze test results
Factors that affect performance and testability
Simulate multiple users
Running tests that require login authentication
Applied Techniques of was
Resources



Introduced
As we move from a traditional CS-structured application to a current popular web-space program, we find ourselves trying to keep up with growing testability requirements and performance requirements. One of the biggest challenges is how to determine how many users your program can support. How do you face this challenge? Setting clear performance goals and using the Web Stress test tool can be a good start.

This article will explain how to stress test your ASP program and will introduce Microsoft's Stress testing tool-Web application Stress Test Tool (WAS). In the next chapter, you'll learn the basics of stress testing, and you'll learn some of the necessary skills. , through these studies, you will be able to test and modify your program more effectively according to the results of the test.

Plot
Suppose you are going to publish an ASP program that is expected to be used by 1000 of users. You know clearly that your program can handle at least two concurrent users, because you and your partner can click on the ASP program all day without any problems. You are wondering whether two users can accurately reflect the compression capability of your program. Of course you can use standard test methods (publish your program and expect the best results), yet you decide to test your program's performance in advance. That's a good sign!

Test requirements
To better test your ASP program, you first need to decide how much pressure your program will need to face in the future. Simply put, the pressure or load can be broken down into the following numbers:

· Minimum number of users. (What is the minimum number of users of this program?) Usually this number can be daily or not weekly or monthly clicks-Of course you can also break down into a more manageable number-hourly traffic,

· Total number of concurrent users. (What is the worst-case situation at the highest peak?) Make a plan accordingly. Hope to work normally and effectively under pressure.

· Request Peak value. (How many ASP pages are needed per second?) This is perhaps the most important factor in measuring the ability of an ASP program to respond to user requests.

It is often difficult to determine the number of users and concurrent users for your program, and before your program is actually used. Especially network programs. Even LAN programs often face increased user problems, so accurate estimates of user volume will be difficult. When you don't know how to start, it's best to start with the basics:

Issues to consider on the Internet:
· Analyze your existing IIS logs. This number suggests some real probabilities.

· How Popular Will your site be? The popular site will have 1 million or more visits a day. Not so popular? So suppose there are some different situations? Suppose you have more than 1000 user groups? Can you solve scalability problems by adding more hardware devices? Or will the architecture of your program become a bottleneck?

· What is the worst-case scenario? Ask your friend, is this going to happen?

Issues to consider for an intranet:
· Similarly, analyze your existing IIS logs.

· Is this ASP program available to everyone? How many machines are there in the company intranet? Can your system administrator tell you something about the peak traffic in the network?

· Does this program have a specific user object? HR HR department only? How many human resources department employees are in use?

· What's the worst-case scenario?

If you cannot determine the appropriate load in advance, it is your best bet to determine the maximum limit for your program. How many ASP response results can you produce in 1 seconds if clicked by 10 users? What about 100? What about 1000? What about 10,000? Keep track of your benchmarks. When you get your traffic log from actual use showing that you are approaching your limits, you will not only know what your current limits are, but you will have time to prepare for the solution.

Introducing the Test tool was

Although there are a lot of stress test tools to choose from, in this article, I will focus on was (formerly known as Homer), is the current Microsoft's standard Web page stress testing tool. If you are already familiar with Webcat, you will be thrilled to find that was is a convenient way to import existing Webcat scripts. If you've used InetMonitor before, you'll be thrilled to find that was also GUI based (this would be a good add-on for many users of Webcat who use the command line). Another advantage is that it's free, and one of my best friends often says, "if it's free, it's mine." "In addition to its price advantage, this tool provides complete functionality and is constantly upgrading." Microsoft.com often use it, so they will understand the importance of this tool.

But you don't have to listen to me too much, just try it on your own. At the end of the article I will provide a list of some third-party stress testing tools that you can decide on your own. The bottom line is that you need a tool that can put your ASP program under load and test it before it is released.

Start using was
I'll show you how to use this tool to test an ASP page for the first time. I will also explain how to use the signed login test and multiuser concurrent access test, because these things will make beginners confused.

First you need to download and install this tool. You can get the latest version from the link below

Http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/intranet/downloads/webstres.asp . There will also be an introductory guide to the tool on this site, and you can go back and see it anytime.

Here are a few things to keep in mind when installing:

· Do not install was on your test target server, install on another machine to ensure accurate test results.

· ADO2 is required on the machine on which was is installed. More than 1 versions. If the Oledb32.dll version is not 2.10.3711 or above, ADO is automatically installed by was.

· After installation you will have a complete setup log, which defaults to the \program Files\Microsoft Web application Stress Tool\install. LOG.

· If you have installed an older version of was, the data file will remain intact when updated. was using the access. mdb file as the data store file. Was's initial. mdb package is was.mdb and can be found in the program installation path.

· Was in the registry Hkey_local_machine\software\microsoft\was store registration information.

Before running our newly installed was, we created a simple ASP script as a test page. Create a new ASP page called Myasppage.asp, and then insert the following script:

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" full file path
Response.Write (strFilePath & "<BR>")
Set OTS = Ofso.opentextfile (strfilepath,forappending, True)
Ots.writeline ("Session Id:" & Session.SessionID & Chr () & _
' Time: ' & Cstr (now ())
%>
</BODY>
</HTML>
This ASP script inserts SessionID and its active time in a text file so that we can easily verify that our ASP page is executing correctly. Once you are familiar with the tool, you can point to your actual ASP page for real testing.

Place your ASP page in the appropriate directory on the server so that it can be accessed anonymously. We'll try the signature access test later, but now we need to run one of the most basic tests. Browse your page with the full path URL, including your server name. For example, a complete URL looks like a http://MyServer/MyVirtualDirectory/MyASPPage.asp. Once you have successfully browsed your ASP page (be sure to check the MyFile.txt file, the file will be written in the physical location of the virtual directory), you can run was to do the actual test.

When you first run was, the following dialog box appears:


Figure 1. Create a new script

While other options are tempting, let's choose manual first. In the future you can also create a new script from the scripts of the menu or from the new Script icon at the tool stop point.

Welcome to the Scripting Browsing interface. The left-hand side of the window lists your scripts in a tree-shaped structure. On the right-hand side of the window you can modify your script settings.

Tree-like list in the left-hand window click New script to activate the browsing of the script. Enter the name of your server in the server input box. In the first item of the script item, select Get as your action. Enter your ASP address in path with the virtual directory as the start character. See figure Figure 2 as follows:


Figure 2. Enter the URL in the Path field

At this point, you can click the run script arrow symbol on the toolbar to execute your script (make sure you have the correct script on the left window). The script needs to run for about 1 minutes before generating a profile performance report.

Analyze test results
You can click on the reports icon on the toolbar to see the resulting report. This will result in a new tab with the Script tab. Reports are stored in an outline view. First of all, in your report below the point result codes, this will give you a quick impression of whether the test has any problems. If you see a status code that is not 200, you may need to investigate what has happened, and the usual problems include branding and incorrect URL paths.

Point overview, you will see a brief and quick analysis of this test activity. From an ASP's technical point of view, Request per Second is a key value that requires in-depth analysis. The higher the value, the better. Typically, if you can't determine a specific goal from the use of reports and budgets, you can have the ASP's requests per second value above 30, of course the ASP is not connected to the database or uses other components. Because it can be foreseen, connecting to the database will add to the burden of the program.

Although there are request per second This counter is included by default in was, you may want to add other counters. You can add additional counters by adding counter after you click the Perf counters icon. A particularly useful counter is the ASP Requests Queued, which is often the key to identifying a blocked or permanently resident page or component. The resources for analyzing ASP performance are:

· Tuning Internet Information Server performance

· Navigating the Maze of Settings for Web Server performance optimization

· IIS 4 Resource Kit

Factors that affect performance and scalability
Server composition, database access, and other factors can greatly reduce the ASP request per second value. Different configuration options can also play a different role, and here I want to point out several common factors:

· If you are accessing a database, do you have a connection pool? For more information about connection pooling, see pooling in the Microsoft data Access components.

· Are you using ASP session variables to store state? The session variable can quickly affect testability. They require server resources, and if you want to increase the machine to extend performance, they can be a hindrance because the session is connected to a particular machine. Stateless is the way to maximize scalability. About the replacement of the session please refer to this article: Howto:persisting Values without session.

· Do you store components with Visual Basic in Session state? Get rid of them now. Visual Basic objects in the session cause thread dependencies and interfere with the thread pool that is hitting IIS. This is a complex subject, but the empirical approach to it is to not store single-threaded Apartment (STA) objects in the session. If you need to keep objects in session, they should be labeled "Both" and you will need to aggregate these free threads to become a collection. The Active Template Library (ATL) can create such monsters.

· Is your Web program limited to running in its own memory space? In fact, we recommend process protection. However, if you need to squeeze out some extra performance, running your Web program in the process will save some of the overhead of cross process collections.

· When it comes to Microsoft Transaction Server (MTS) components, if the component is run as a server package rather than a library package, there will be significant performance differences. A common recommendation is to set up a network program to run in its own memory space, and then run the MTS component in the library package.

Simulating multiple user scenarios
I'll briefly describe how to simulate a multiuser request in was. You need to do two things:

1. Change concurrent connections in the Settings panel.

2. Create users at the user, at least to create more users than you specify in concurrent connections.

To change the number of concurrent users, click the Settings icon. If less than 100 users, you can set the stress level directly, to simulate more than 100 users, you also need to set stress multiplier. The basic formula is: Number of users (threads) = Stress level * Stress multiplier. If you want to simulate 1,000 users, you can set the Stress level to 100 and Stress multiplier to 10.

If you try to run a script before you have set up enough users, you will get a warning. You can change the number of users by using the Point users icon, and you will see a default group in the right window. Double-click the default group to expand your user list, and if you are allowed to access it anonymously, simply fill in the code for the new user and click Create.

Run a test that requires a signed login
If you want to run a page that requires a signed login, you need to create the appropriate username and password so that was available at run time. This is also set by the users. You can remove the current list of users by removing all from the start, and then add the users you need, and you can also choose to import user names and passwords from a text file.

However, you need to make sure that these users have a valid account number and that they have access to the IIS server. If you are using the Basic Authentication user account, you can test the account by submitting a certificate in your browser and writing a request.servervariables ("Auth_User") value in the text file will help a lot. Our revised ASP code will look like this:

Ots.writeline ("Session Id:" & Session.SessionID & Chr () & _
' Time: ' & Cstr (Now ()) & "AUTH USER:" & Chr (+) & Request.ServerVariables ("Auth_User"))
Tips and hints for using was
As an end, I will provide some tips and hints, as well as some experience summary:

· Adjust the storage of your site's log files, as this file will grow quickly (see IIS documentation)

· By setting the Hkey_local_machine\software\microsoft\was\sessiontrace DWORD in the registry to 1, you can track was's activity in a debug fashion

· If your was report shows an error, be sure to check the event log, browse your page in the tool's external browser, and check the server's log: \winnt\system32\logfiles\w3svci

· If your test client machine has more processor usage than%85, you may need to add more test clients

· Some of the more interesting topics appear in the documents of was: Page Groups, Query Strings, Cookies, WEB application Stress Object model and active Server Page Client (this will give you the ability to remotely control the test client via the Web

Please note that this is a tool with no technical support to send your questions to webtool@microsoft.com. You can search for some common problems with the Web application Stress tool this network. You can also program the tool and have a reference to the object model on the same site.

Resources
To get more information, the tutorial on was's website was a good place to go. Of course, be sure to read the online help that came with was-especially a topic called Web Stress Testing Overview.

· Webhammer. A tool that is used by serverobjects to test network programs and servers

· LoadRunner. A stress test tool made by Mercury interactive that can be used to anticipate the system performance and performance of enterprise-level programs

· Enterprise Monitor. Produced by MediaHouse software to monitor, communicate and restore your intranet and Internet network

· Extreme Soft ' s PerfMon. A tool for Microsoft Transaction Server that provides direct MTS monitoring from performance monitoring.



J.d Meier was born and grew up on the east coast of the United States. Since paying attention to Greeley's advice, he has become a development support engineer, focusing on server-side components and Windows DNA applications involving MTS and ASP technologies.