ASP optimization: Load Test Your ASP program
Introduced
As we move from the traditional CS-structured application to the 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 show you 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 will learn the basics of stress testing and learn the necessary skills , through these studies, you will be able to test and modify your program more effectively based on the results of the test.
Plot
Suppose you are going to publish an ASP program that expects 1000 users to use. You know that your program can handle at least two concurrent user visits, 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 capabilities of your program. Of course you can use standard test methods (publish your program and expect the best results to appear), however you still decide to test your program's performance in advance. This is a good omen!
Test requirements
In order to better test your ASP program, you first need to decide how much pressure your program will 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 value can be a daily or no week or a monthly amount of clicks-you can, of course, break it down into a more manageable number-hourly traffic.
· The total number of concurrent users. (What is the worst situation at the peak?) Make a plan accordingly. Hope to work normally and efficiently under stressful conditions.
· Request Peak value. (How many ASP pages need to be generated per second? This may be one of the most important factors 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 it is before your program is actually used. Especially network programs. Even local area network programs often have to face the problem of user increase, so accurate estimate of user volume will be difficult. When you don't know how to start, it's best to start with the basics:
Issues that the Internet needs to consider:
· Analyze the IIS logs that you already have. This value will imply some real odds.
· How Popular Will your site be? Popular sites will have 1 million or more visits per day. Not so popular? So what are some different scenarios? Suppose you have more than 1000 of your user base? Can you solve extensibility problems by adding more hardware devices? Or will your program's architecture become a bottleneck?
· What is the worst case scenario? Ask your friends if these things are going to happen?
Issues that your intranet needs to consider:
· Similarly, analyze the IIS logs that you already have.
· Is this ASP program available to everyone? How many machines are there in the company intranet? Can your system administrator tell you something about peak traffic in your network?
· Does this program have specific user objects? Just HR HR department? How many people in the HR department are using?
· What is the worst case scenario?
If you cannot determine the appropriate load in advance, then determining your program's maximum limit will be your best option. If you are clicked by 10 users, how many ASP responses can you generate in 1 seconds? 100 of them? 1000 of them? 10,000 of them? Keep track of your benchmarks. When you get your traffic log from actual use to show that you are approaching your limit, 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
There are a lot of stress test tools to choose from, but in this article I will focus mainly on was (formerly known as Homer), which was the current Microsoft standard Web Stress test tool. If you're already familiar with Webcat, you'll be thrilled to find that was can easily import an existing Webcat script. If you've used InetMonitor before, you'll be thrilled to find that was is also based on the GUI (which would be a good addition to many users using the command line Webcat). Another advantage is that it's free, and a good friend of mine often says, "if it's free, then it's mine." "In addition to its price advantage, this tool also provides complete functionality, and is constantly upgrading the update. Microsoft.com often want to 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 yourself. I will provide a list at the end of the article that lists some of the third-party stress testing tools that you can decide what tools to choose. The bottom line is that you need a tool that can put your ASP program under load and test it before it is released.
Getting Started with was
I'll teach you how to use this tool for the first time to test an ASP page. I'll also show you how to use signed login tests and multiuser concurrent access tests, because these things can 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 this tool on this site and you can always go back and see it.
Here are a few things to keep in mind when installing:
· Do not install was on your test target server and install it on a different machine to ensure accurate test results.
· ADO2 is required on the machine where was is installed. More than 1 of the version. If the Oledb32.dll version is not 2.10.3711 or above, ADO will be automatically installed by was.
· After installation you will have a full installation log, which will default to \program Files\Microsoft Web application Stress Tool\install. LOG.
· If you have installed an older version of was, the update will keep the data file intact. was uses an access. mdb file as the data store file. The initial. mdb package for was is was.mdb and can be found in the program installation path.
· Was stores registration information in the Registry's Hkey_local_machine\software\microsoft\was.
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 insert the following script:
Myasppage.asp
<%@ Language=vbscript%>
<% 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) & _
"Time:" & Cstr (Now ()))
%>
This ASP script will insert 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 this 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 again later, but now we need to run one of the most basic tests. Use the full path URL to browse your page, including your server name. For example, a full URL looks like http://MyServer/MyVirtualDirectory/MyASPPage.asp. Once you can successfully browse your ASP page (be sure to check the MyFile.txt file, this file will be written by the program in the physical location of the virtual directory), you can run was to do the actual test.
When you run was for the first time, the following dialog box appears:
Figure 1. Create a new script
While other options are tempting, let's start by choosing Manual. In the future you can also create a new script from the menu's scripts or by taking the new Script icon from the tool bar.
Welcome to the Scripting Browser 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.
In the left-hand window, in the tree-like list, click New script to activate the browser. 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 2 below:
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 in the left window). This script needs to run for about 1 minutes before generating a profile of the performance report.
Analyze test results
You can see the resulting report by the reports icon on the tool bar. This will result in a new tab that is adjacent to the Script tab. The report is stored in an outline view. First, at the bottom of your report, click Result Codes, which will give you a quick impression of what's wrong with this test. If you see a status code other than 200, you might want to investigate what's going on, and the usual problems include attribution and the incorrect URL path.
Point overview, you will see a brief and quick analysis of this test activity. From the technical point of view of ASP, Request per Second is a key value that needs to be analyzed in depth. The higher the value, the better. Typically, if you cannot determine a specific goal from the usage report and budget, you can make the ASP's requests per second value higher than 30, and of course the ASP is not connected to the database or using other components. Because it is foreseeable that connecting to the database increases the burden on the program.
Although there is a request per second This counter is included by default in was, you may want to add additional counters. You can add additional counters by adding counter after you click on the Perf counters icon. A particularly useful counter is the ASP requests Queued, which is often the key to identifying a blocked or long-lived page or component. 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 measurable properties
Server composition, database access, and other factors will greatly reduce the ASP's request per second value. Different configuration options will also play a different role, here I would like to point out a few frequently occurring 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 the ASP Session variable to store the state? Session variables can quickly affect testability. They require server resources, and if you want to add machines to scale performance, they can be a hindrance because the session is associated with a particular machine. Stateless is the way to maximize scalability. For an alternative to the session, please refer to this article: Howto:persisting Values without session.
· Do you have Visual Basic components stored in the session state? Get rid of them now. Visual Basic objects in the session can cause thread affinity and interfere with the thread pool that is attacking IIS. This is a complex subject, but the experience of satisfying it is: do 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 need to aggregate these free threads yourself into a collection. The Active Template Library (ATL) can create monsters like this.
· Is your network 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 network program in the process will save some of the overhead of cross-process collections.
· When it comes to Microsoft Transaction Server (MTS) components, there will be a noticeable performance difference if the component is running as a server package rather than a library package. 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 multi-user scenarios
I'll briefly show you how to simulate a multiuser request in was. You need to do two things:
1. Change the concurrent Connections in the Settings panel.
2. Create a user at the users, at least to create more than the number of users you specified in concurrent connections.
To change the number of concurrent users, click the Settings icon. If you have fewer than 100 users, you can set the stress level directly, and to simulate more than 100 users, you must also set stress Multiplier. The basic formula is: Number of users (number of 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 the script before you set enough users, you will get a warning. You can modify the number of users by using the Click Users icon, and you will see a default group in the right window. Double-click the default group to expand your list of users, and if you are allowed anonymous access, simply fill in the new user's code and click Create.
Run a test that requires a signature login
If you want to run a page that requires a signed login, you need to create an appropriate user name and password so that was can be used at run time. This is also set in the users. You can get rid of the current list of users by removing all from the beginning, then add the users you need, or you can choose to import the user name and password from the text file.
However, you need to make sure that these users have valid accounts and that they have access to the IIS server. If you are using Basic Authentication user account, you can test this account by submitting a certificate in your browser, it will be helpful to write the value of Request.ServerVariables ("Auth_User") in the text file. Our modified 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
To conclude, I will provide some tips and hints, as well as some experience to summarize:
· Adjust the storage of log files for your site as this file will grow quickly (see IIS documentation)
· By setting the DWORD of Hkey_local_machine\software\microsoft\was\sessiontrace in the registry to 1, you can trace the activity of was in a debug manner
· If your was report shows an error, be sure to check the event log, browse your page in the tool's external browser, and then 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 will 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 test the client via web Remote control)
Please note that this is not a technical support tool, send your questions to Shanghai Men's Hospital mailbox. You can search for some common problems with Web application Stress tool. You can also program this tool and have a reference to the object model on the same website.
Resources
For more information, the tutorial on was's website is 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 for testing network programs and servers by serverobjects
· LoadRunner. A stress test tool made by Mercury interactive that can be used to foresee system performance and performance of enterprise-class programs
· Enterprise Monitor. Produced by MediaHouse Software, for monitoring, notifying and recovering your intranet and Internet network
· Extreme Soft ' s PerfMon. Tools for Microsoft Transaction Server to provide direct MTS monitoring from performance monitoring.
J.D. Meier was born and raised on the east coast of the United States. Since noticing Greeley's advice, he has become a development support engineer focused on server-side components and Windows DNA applications involving MTS and ASP technology.
ASP optimization: Load Test Your ASP program