I can't put enough pressure to it: load your ASP program
J.d. meier
September 27, 1999
content
Introduction of plot test demand introduction Test tool WAS analysis test results affect performance and measuring factors Simulation multi-user running test WAS application skills resources required to log in to authentication
Introduction
When we transfer from traditional CS structures to the current popular Web space program, we found that we have tried to keep up with the growing measurable demand and performance requirements. One of the biggest challenges is how to determine how many users can access by your program. How do you face this challenge? Setting a clear performance goal and use a Web Pressure Test Tool will be a good start.
This article will introduce how to perform pressure testing of your ASP program, and will introduce Microsoft's pressure test tools - Web Application Stress Test Tool (WAS). In the next chapter, you will learn the pressure test Basics, and also learn some necessary techniques. Through these learning, you will be able to test and modify your procedures based on the results of the test.
Plot
Suppose you will have an ASP program that is expected to have 1000 users. You know your programs at least two concurrent users access, because you can click on this ASP program all day without any problems without any problems. You are suspected that the two users can accurately reflect the pressure relief capabilities of your program. Of course, you can use standard test methods (release your program, then expect the best results), however, you still decide to pre-test your program performance. This is a good sign!
Test demand
In order to better test your ASP program, you first need to decide how much pressure is needed in the future. Simply put, the pressure or load can be broken down into the following numbers:
· The minimum number of users. (How much is the minimum number of users of this program? Usually this value can be a daily or no week or monthly click quantity - of course you can also break down into a more controllable value - per hour visits,)
· Concurrent users' total. (What is the bad situation at the highest peak? Corresponding plans. I hope to work properly in the pressure of pressure.)
· Request a peak value (how much ASP page is needed per second? This may be a most important factor when measuring an ASP program to respond to user requests.)
To determine the number of users and concurrency users, it is usually very difficult, and it is before your program is actually used. Especially the network program. Even the local area network program also often faces the problem of users, it is expected that the user will be difficult. When you don't know how to start, the best start:
INTERNET needs to be considered:
· Analyze the IIS log you already. This value implies some actual probability
· How many popularity will your site? A popular site will have 1 million or more visits a day. Will n't it be so popular? So do you assume some different situations? Suppose you have more than 1,000 user groups? Can you solve the extensibility problem by adding more hardware devices? Or, do you become a bottleneck in the architecture of your program?
· What is the worst situation? Do you have any of your friends?
Intranet needs to consider the question:
· Similarly, analyze your IIS log.
· Is this ASP program to give each person? How many machines have there been on the company's internal network? Can you tell you something about the traffic of the network?
· Is this program a specific user object? Just HR Human Resources Department? How many employees in the Human Resources? · What is the worst situation?
If you can't decide your proper load in advance, then determine your program's highest upper limit will be your best choice. If you are clicked by 10 users, how much ASP response results can you generate within 1 second? 100? 1000? 10,000? Record your benchmark. When you get your traffic log from actual use, when you are approaching your limit, you will not only know what your current limit is, and you will have a time to solve.
Introduction Test Tools WAS
Although there are many pressure test tools to choose, but in this article, I will focus mainly introduce WAS (that is, the previous so-called HOMER), WAS is the current Microsoft standard web pressure test tool. If you have been familiar with Webcat, you will be excited to discover that WAS can easily import existing webcat scripts. If you have used iNetmonitor before, you will be excited to discover that WAS is also GUI (which will be a good additional feature for many webcat users using the command line). Another benefit is that it is free, I am often said, "if it is free, then it is mine." In addition to its price advantage, this tool also provides a complete function, but also constantly Upgrade update. Microsoft.com often uses it, so they will understand the importance of this tool.
But you don't need too much geographic, just try yourself. I will provide a list at the end of the article, list some third-party pressure test tools, you can decide what tools you choose. The bottom line is that you need a tool, you can put your ASP program to the load, test it before publishing it.
Start using WAS
I will teach you how to use this tool for the first time to test an ASP page. I will also introduce how to use the signature login test and multi-user testing test, because these things will make the beginners foggy water.
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 be on this website. There will be a gateway guidance on this tool, you can always Go back and see.
The following is a few points to pay attention to when installing:
· Do not install the WAS on your test target server, install it in other machines to ensure accurate test results.
• There is a version of ADO2.1 on the machine where WAS is installed. If the version of OLEDB32.DLL is not 2.10.3711 or more, ADO will be installed automatically by WAS.
· You will have a complete installation log after installation, which will be in / program files / microsoft Web Application Stress Tool / Install.log.
· If you have already installed the old version of WAS, the data file will be kept in good time. WAS uses the Access .mdb file as a data storage file. The initial. MDB package is WAS.MDB, which can be found in the program installation path.
· WAS is stored in the registry hkey_local_machine / Software / Microsoft / WAS.
Before running our newly installed WAS, we create a simple ASP script as the test page. Create a new ASP page called MyaSppage.asp, then 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 (32) &_
"Time:" & CSTR (now ()))
%>
This ASP script will insert sessionID and its activity time in a text file so that we can easily confirm that our ASP page is executed correctly. Once you are familiar with this tool, you can point to your actual ASP page for true testing.
Place your ASP page in the proper directory of the server so that it can be accessed anonymous. We will tested tested to tests later, but now we need to run a most basic test. Browse your page with a full path URL, including your server name. For example, a complete URL looks like http: //myserver/myvirtualdirectory/myasppage.asp. Once you can successfully browse your ASP page (Be sure to check myFile.txt file, this file will be written in the physical location of the virtual directory), you can run WAS to do actual tests.
When you first run WAS, the following dialog will appear:
Figure 1. Create a new script
Although other options are also very attractive, let us first select this. In the future, you can also create a new script from the scripts of the menu or Script icon in the tool.
Welcome to the script browsing interface. The window of the left hand lists your script with a tree structure. In the window of the right hand, you can modify your script settings.
The tree list in the window of the left hand is clicked in New Script to activate the script browsing. Enter your server's name in the Server input box. In the first item of Script item, choose GET as your actions. Enter your ASP address in Path to start with the virtual directory. See Figure Figure 2 as follows:
Figure 2. Enter the Url in the path field
At this time, you can click the Run Script arrow symbol on the toolbar to perform your script (you must make sure you have a correct script on the left window). This script needs to run about 1 minute before generating a summary performance report. Analysis test results
You can click on the Reports icon on the toolbar to see the report. This will produce a new Tab coming to the Script Tab. The report is stored in an outline view. First, in your report, you will give you a fast impression, this test has a problem. If the status code you see is not 200, you may need to investigate what problems have occurred, and the usual issues include signature and incorrect URL path.
Point Overview, you will see a brief and fast analysis of this test activity. From an ASP's technical point of view, Request Per Second is a key value that needs to in-depth analysis. The higher the value, the better. Typically, if you can't decide a specific target from the use report and budget, you can make the ASP's Requests Per Second value above 30, of course, this ASP is not a database or other components. Because it is foreseeable, the connection database will add the burden on the program.
Although there is a Request Per Second that is included in WAS by default, you may want to add other counters. You can add additional counters after you click the PERF Counters. A particularly useful counter is ASP Requests Queued, which is often the key when identifying a block or component of a blocking or long-term resident. About the analysis of ASP performance is:
· TUNING Internet Information Server Performance
· Navigating the Maze of settings for web server performance optimization
· IIS 4 Resource Kit
Effect of performance and measurable factors
Server consists, database access, and other factors greatly reduce the ASP's Request Per Second value. Different configuration options will also play different roles, here I want to point out several common factors:
· If you are accessing a database, do you have a connection pool? For details on connecting pools, please see Pooling in The Microsoft Data Access Components.
· Do you store the status in using the ASP session variable? The session variable will quickly affect the detergent. They need server resources, and if you want to increase the machine to extend performance, they will hinder, because the session is related to a specific machine. No status is a way to maximize scalability. For replacement of session, please refer to this article: HOWTO: PERSISTING VALUES WITHOUT SESSION.
· Do you store components with Visual Basic in the SESSION state? Now remove them. The Visual Basic object in Session causes thread-dependent and interferes with the thread pool of the IIS. This is a complex topic, but the experience method satisfying is: Do not store Single-Threaded Apartment (STA) Objects in the session. If you need to reserve objects in Sess, they should be marked as "Both", and you need yourself to aggregate these free threads into a collection. Active Template Library (ATL) can create such a monster. · Is your network program to be limited to its own memory space? In fact, we recommend the process protection. However, if you need to squee out some extra performance, run your network program in the process will save some of the overhead of intersection.
• When the component is running as a server package, it will have a significant performance difference if the component runs as a server package instead of the library package. A usual suggestion is to set the network program to run in its own memory space and run the MTS component in the library package.
Simulate multiple users
I will briefly describe how to simulate multi-user requests in WAS. You need to do two things:
1. Change the CONCURRENT Connections in the Settings panel.
2. Create a user in Users, at least to create more than the number of users you specified in Concurrent Connections.
To change the number of concurrent users, point Settings icon. If less than 100 users, you can directly set Stress Level, you need to simulate more than 100 users, you must also set Stress Multiplier. Basic formulas: User number (number of thread) = Stress Level * Stress Multiplier. If you want to simulate 1,000 users, you can set Stress Level to 100 and Stress Multiplier is 10.
If you try to run a script before you set enough users, you will get a warning. You can modify your number of users by clicking on the window, you will see a default default group on the window. Double-click the DEFAULT group exhibition to open your user list, if you are allowed to access anonymous access, then you just fill in the new user code then click CREATE.
Run the test that requires sign-on login
If you want to run the page that needs to be logged in, then you need to create a suitable username and password so that WAS can be used at runtime. This is also set in Users. You can get the current user list through the Remove All, then add the user you need, and you can also choose to import username and password from text files.
But in any case, you need to make sure that these users have a valid account, and they can access the IIS server. If you are using a Basic basic authentication user account, you can test this account by submitting a certificate in your browser, writing Request.ServerVariables ("Auth_user") this value will have a lot of help in text files. Our revised ASP code will look like this:
OTS.Writeline ("session ID:" & session.SessionID & CHR (32) &_
"Time:" & CSTR (now ()) & "Auth User:" & Chr (32) & Request.ServerVariables ("Auth_user")) Use WAS skills and prompts
As an end, I will provide some techniques and prompts, and some experience summary:
· Adjust the storage of log files in your website, because this file will increase quickly (see IIS document)
· By setting the HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Was / SessionTrace in the registration table 1, you can track the activity of WAS with debugging way
· If your WAS report shows an error, be sure to check the Event log, browse your page out of the browser, then check the server's log: / Winnt / System32 / Logfiles / W3SVCI
· If your test client machine's processor usage exceeds% 85, you may need to add more test clients.
· Some more interesting topics will appear in the WAS document: Page Groups, Query Strings, Cookies, Web Application Stress Object Model and Active Server Page Client (this will make you capable over the web remote control test client)
Note that this is a tool without technical support, sending your problem to WebTool@microsoft.com. You can search for some common problems on the web application stress tool. You can also program this tool, with reference to an object model on the same website.
Resource
To get more information, Tutorial on WAS is a good place. Of course, please be sure to read the online help with WAS - especially a topic called Web Stress Testing Overview.
Webhammer. A tool for testing network programs and servers made by ServerObjects
· LoadRunner. A pressure test tool made by Mercury Interactive can be used to foresee the system performance and performance of enterprise-class programs.
Enterprise Monitor. Produced by Mediahouse Software, for monitoring, notification, and recovery your intranet and internet network
· Extreme Soft's Perfmon. Tools made for Microsoft Transaction Server can provide direct MTS monitoring from performance monitoring.
J. D. Meier is born and grows in the East Coast of the United States. Since paying attention to Greey's recommendations, he became a development support engineer, focusing on server-side components and Windows DNA applications involving MTS and ASP technology.
