Use WCAT for IIS stress testing)

Use WCAT to perform IIS stress test favorites
How to Establish WCAT

Microsoft's Web Capacity Analysis Tool (WCAT) is an essential tool for testing your customer-server network configurations. This tool simulates a variety of scenarios on your network, allowing you to determine the optimal configuration of your network and server. WCAT is designed to evaluate Internet servers running on Microsoft Windows NT Server and Microsoft Internet Information Server (IIS, but you can use it on almost all types of Web servers. However, there is a limitation: ASP and ISAPI are not running on UNIX, so they cannot be tested in that environment. The best thing about this tool is the price-it can be downloaded for free. The downloaded content contains detailed documents that are easy to read and understand. If you want to use WCAT, I suggest you read these documents first.
WCAT provides 40 ready-to-run workload simulation, allowing you to test downloading pages or content of various sizes from the server at different levels of connections. A detailed list of these tests is displayed in the document. You can use the extension of ASP, Internet Access Application Programming Interface (ISAPI), and public Gateway Interface (CGI) Applications to test server performance. This is useful even if you do not use these extensions now, because you can test the extension before configuration. In addition, the WCAT test runs a simulation to test responses on lower-level communication servers. These lower-level communication includes the encrypted SOCKET protocol Layer (SSL) 2.0 and 3.0, private communication technology (PCT) 1.0 encryption method and Hypertext Transfer Protocol (HTTP) persistence (allow connection maintenance after initial request Completion ).

If you need more extensive tests, you can create your own custom simulation and run them with WCAT. You can even test servers connected to more than one network and use cookies. You can also use it to test your local network.

How to Establish WCAT
Now you may want to take a look at WCAT, so let's take a look at the typical settings that need to be done before starting the test. To run a WCAT test, you need four components: a server, a customer, a controller, and a network. When you run the test, the Controller and client run different WCAT, and the server uses the WCAT file to respond to the request (those files depend on the simulation you are running ).

■ Server

The server is responsible for responding to connection requests, managing connections, receiving, processing, and responding to requests to Web content (Web pages. If you want to install all static files for testing, you need MB space on the hard disk. ASP testing requires less than 110 KB of space. Apart from the specific content you want to test, you do not need to install anything on the server. You must install a TCP/IP and restrict it to the network adapter.

On Windows NT, when you set server components, the setup program automatically copies necessary files to the appropriate location. If you are not running Windows NT, you must do some work yourself. Install the Server File and copy the directories starting with perfsize from the www root directory of the Windows NT Server to the server you want to use. Do not forget to copy the files in these directories.

■ Client

The client is responsible for making the server work hard. Specifically, in a WCAT test, you can configure the customer at different levels by specifying the number of customer browsers in the test; the size, type, and speed of customer requests; the frequency of sending requests and the requested page; test duration. You do not have to create a client for each customer you want to test. Each WCAT client test runs in its own program, so more than one customer can run on each client. These are so-called virtual customers. Each client can run a maximum of 200 customers, allowing you to test a staggering number of connections with a small amount of resources (Note: Testing 200 physical customers is just an approximate number. 200 physical customers will cause greater load to the server ).

You need to monitor the memory usage on the computer. If the customer uses more than its physical memory (in other words, it performs content exchange frantically), then you will feel the speed is reduced, and the number of virtual customers should be reduced. Generally, customers do not have problems unless your hardware conditions are too bad.

The Windows NT Server or Windows NT Workstation (4.0) must be installed on the client, and the hard disk has 1 M available space. The TCP/IP is installed and restricted to the network adapter.

■ Controller

The WCAT controller manages WCAT tests. This separates the actual tests on other machines from the load of test management. The controller uses input files that specify how to run the test and when the test ends, and then write the results to the output file.

To run a prepared test, the controller must contain three input files. If you want to customize the test program, you can use these files of your own version. You need to include a configuration file that specifies the number of customers, number of virtual customers, and test duration. The configuration file name extension is. cfg, which is based on the name of the test being run. Therefore, if the test name is test1, the configuration file is named test1.cfg. Another input file you need is your script file. This file contains the name of the page requested by the slave server. The extension of the script file is. scr. According to the preceding example, your script file name should be test1.scr. The third required input file is a distributed file, which specifies the frequency of customer requests. The extension of this input file is. dst, which is named test1.dst in the preceding example.

There is also an optional input file, the performance counter file, which can be used to monitor the performance of the counter. Its extension is. pfc. In the above example, this file should be named test1.pfc.

With the input file, let's talk about the output file. The Controller generates a log file that contains the statistics collected during the test. The extension of this log file is. log, which is a text file separated by commas (,) and can be edited in a text editor or used as input to a workbook or database. If you specify a performance counter as the input, the Controller will also generate a performance counter result file (Extension:. prf ).

The Windows NT Server or Windows NT Workstation (4.0) must be installed on the host that acts as the controller. There must be 10 MB of available space on the hard disk. You must install TCP/IP and restrict it to the network adapter.

■ Network

The network used for WCAT is only a simple communication connection between your clients, servers, and controllers. The network must use TCP/IP, and the network bandwidth should be 100mbit/s. When you establish a test, make sure that all the machines connected to the network are correctly configured so that you can know that the performance problem is not caused by improper installation.

■ Performance and stress testing

To determine the best performance your Web application may achieve, we recommend the following:

◎ An isolated private network (this is ideal)

Ample customers to give full play to the potential of servers

◎ Adequate network bandwidth (100 Mbps or higher)

◎ Multiple NICs to distribute loads

◎ One multi-processor machine for scalability testing (ideal)

◎ Run the test again to check whether the test result can be regenerated

◎ Check the page in a browser to confirm that the application is correctly set and run.

If you want to test the performance of an application under the average load, you should set some performance indicators (number of pages loaded per second, CPU usage ratio, response time) and strive to achieve these indicators.

If your objective is to perform stress testing, you do not need to use the network and many customers on your own. Putting your application under moderate load is enough to expose the problem; running controllers and a customer on the server is enough. This is certainly more effective than refreshing pages in a single browser. If you want to perform stress testing at a higher level, it is good to use private networks and many customers. In addition, running stress tests on a multi-processor machine is also a good way to discover stream problems.

After you use the setup program to install the required files on each computer, you should configure the customer and controller machines when running WCAT for the first time. You need to know the IP addresses of these machines. You can use the ping command line function of TCP/IP to obtain the IP address, which corresponds to four numbers in square brackets (for example, [11.1.38.2]). These numbers represent the IP address of the machine on the network.

■ Configuration

With the IP address, you can configure the customer and controller. The WCAT controller is configured at the command line prompt. You only need to enter the directory containing the controller (in the default state, this directory is \ webctrl, so you should type cd \ webctrl), and then type the config IP address or computer name. If you want to test multiple networks, use the computer name.

The configuration customer is the same as the configuration controller. At the command prompt, enter the customer's directory and enter the IP address of the config controller name (the Controller name refers to the name of the controller machine and the IP address refers to the client ).

■ Run

There are five steps to run WCAT:

◎ Step 1: Start WCAT customers, controllers, and servers.

Start the WCAT client on the client by going to the client directory at a prompt and typing client (this is a batch file, and the program running is wcclient.exe ). The program tries to connect to the Controller. If the connection fails, the program will be connected in 10 seconds, and the connection will be continued every 10 seconds until you finally stop running wcclient.exe. To stop wcclient.exe, type CTRL + C at the command prompt.

Then, run the wcater program (wcctl.exe) on the Controller to specify the test you want to run. At the command prompt, go to the Controller directory and type the run test name [Switch] (where the test name is the name of the test you are running and the switch is the option ). When you run the Controller program, use the-a server IP address and-n server name. -A switch specifies the server to be tested, and-n switch specifies the server name. In the WCAT document, you can find a list of all the switches that may be used and how to use them.

Start IIS and HTTP services on the server.

◎ Step 2: Prepare

In the preparation phase, the controller sends commands to the client, and the customer starts to send requests to the server. In the preparation phase, the output is not collected because the server's response speed is slower than usual (frequently used pages, objects, and commands are not cached by the processor ).

◎ Step 3: Experiment

In the experiment phase, the Controller instructs the client to send a special request to the server to respond to the server. Collect statistics and send status information to the client. The entire process of controller monitoring testing. At this time, WCAT is determining the performance of your server based on the workload simulation. If you have already specified that you want to monitor performance counters, the Controller will monitor these values during the experiment phase.

◎ Step 4: Cooling

After all the work is done, it will take a cool-down period (you should not want your server cramps, right ?). In the cool-down phase, the Controller instructs the client to stop sending requests. Customers end their operations. Even though the customer continues to collect statistics, the data is no longer stored for output; cooling does not indicate a real workload, so these statistics are useless.

◎ Step 5: report

In the report phase, the customer sends the collected data to the Controller. Once all the data is sent, the Controller closes the customer connection. You need to know that WCAT is still running on your customers, so they will be restored to the initial configuration and try to connect to the Controller. The data collected by the Controller is written into a log file. A line of text written represents a customer, including the total number of pages read, the average number of pages read per second, and the actual number of pages read by each customer. At this time, if you specify that you want to monitor the performance counter, this number will be written to the performance result file.

Analysis result
The information written to the log file includes a file header, result, and performance counter (if you want to include this information), file, and class statistics. The header contains general information about the test, such as the date and time when the test is run, the input and output files used, and the duration. The WCAT document contains detailed information about the header domain and structure, and an example.

There are many details written to the. log file, the most interesting of which is the "read page" table. The first numeric column shows the total number of pages read by all clients. The second column shows the page rate seen by the first client per second. The third column shows the total number of pages displayed by the first client. If you have multiple customers, you will see the speed and total number of each machine later.

The log file result area is a table that summarizes all the data collected during the test. The collected data includes the number of requested pages, response time, connections, and all possible errors. The WCAT document contains the table format and the structure of each column.

If you want to monitor performance counters, some of the WCAT logs detail this content. This data is also displayed in a table, containing the average value of each counter on each page.

The log file area contains a table containing the number of files requested in the test and the number of files received by the customer.

The last part of the log is the statistical data area. The data contained in the log represents the page recovery rate on the customer. Including the number of successfully restored pages, error rate, and the requested ratio of a specific page (in other words, the page class. You can use this data to determine which type of page is most requested.

Use and record performance counters
As mentioned above, you can choose to use WCAT performance counters on Windows NT-based servers. With performance counters, you can measure the usage of processors, physical memory, hard disk subsystems, and memory buffers, as well as the performance of the services used (such as IIS. To use the performance counter, you need to use the-p switch when running the controller. You need to provide a file with the extension. pfc, which specifies the counter you want to monitor. By default, this file is under the \ Scripts directory of the WCAT controller.

Use Sample. pfc

The Sample input file "Sample. pfc" for a performance counter is installed in the \ Scripts directory of the WCAT controller. Each counter to be monitored is listed in a separate row, aligned to the left, with no tabs. You can add a comment to each line and add a # sign at the beginning of each line. Each file contains up to 50 counters .. The syntax of a line in the pfc file is object (instance) \ counter. Object is the name of the project you want to monitor, such as a process. Instance is the name of an object's specific example, and counter is the actual property of the object you want to monitor. To monitor the processor time used by Inetinfo during IIS, add the following entries in the. pfc file. In this example, Processor is an object, inetinfo is an example, and % Processor Time is a counter.

Processor (inetinfo) \ % Processor Time

To ensure that you can monitor objects, run the perfmon.exe function (run perfmon.exe at the command prompt) and select "add to chart" from the editing menu. The following dialog box will prompt you:

 
In the dialog box, you can select objects, examples, and counters from the drop-down menu. Click the explain button to get a description of the meaning of each counter.

The following table lists some counters:

Object count comment
Memory allocated by Active Server Pages
Request Rate per second for ASP requests
Request execution time: the average time used to execute a request
Request waiting time the waiting time of the previous request in the queue
Total number of failed requests
Number of queued requests
Number of rejected requests
Current session
Process (inetinfo) processor time
Special time
User time
The total memory used in the private byte process. If this number grows infinitely, it indicates that some things and some places (such as the isapi asp Component) functions are weakened.
Work settings
Thread Flow Counter

Internet Information Services Global cache hit
Memory available bytes
Page errors per second
Number of bytes received by Web Service (_ Total) per second
Number of bytes sent per second
Current anonymous user
Current Non-Anonymous user
Current connection
Total System processor time
Context conversion per second
System calls per second
Processor (0) (each processor) DPC speed
Number of interruptions per second
DPC queues per second

The results in the performance counter must be written into a special result file, testname. prf (testname is the name of the test ). This is a text file separated by commas (,). It can be read in any standard text editor or used as input to workbooks or databases. However, this file cannot be read directly using PerfMon. This file contains the header information (number of counters, machine name, start time of naming), column header, and a table containing collected performance data. For the complete syntax and usage of this file, refer to the WCAT document.

Now we will introduce more WCAT applications.

Write your own WCAT test script
You can customize the WCAT running scenario, you can specify different command line switches, modify server and client configurations, use your own ASP, ISAPI or CGI scripts, and change the input files of customers and controllers. In the previous section, I talked about the ability to change the performance counter file. You can also change the configuration (. cfg), script (. scr), and allocate (. dst) files as needed.

By default, the configuration file is located in the \ webctrl directory of the controller. The information in this file includes the number of buffers used in the test, the number of clients to be used, the number of streams to be used, and the test duration.

To determine the script required for running the test, you can modify the script file. In this file, you can specify the specific ASP you want to test, as well as ISAPI and CGI extensions. Below is a sample script document in the WCAT document.

######################################## ###############################

#

# Test script file for WCAT

#

######################################## ###############################

# Format of Script Specification:

#

# ClassId Operation Files

# Note: Operation Strings are case insensitive

#

# Plaza Welcome page =>

NEW TRANSACTION

ClassId = 1

NEW REQUEST HTTP

Verb = "GET"

URL = "/scripts/welcome. py"

# Click Repeat Shopper => Plaza lolobby

NEW TRANSACTION

ClassId = 2

NEW REQUEST HTTP

Verb = "GET"

URL = "/prd. I/pgen/plaza/JQ04Q9JF66SH2JS700Q79TREBNBGAU1M/plaza1.html"

# Click AG => AG lolobby

NEW TRANSACTION

ClassId = 3

NEW REQUEST HTTP

Verb = "GET"

URL = "/prd. I/pgen/ag/JQ04Q9JF66SH2JS700Q79TREBNBGAU1M/lobby.html"

# Click Big Picture

NEW TRANSACTION

ClassId = 4

NEW REQUEST HTTP

Verb = "GET"

URL = "/prd. I/pgen/ag/JQ04Q9JF66SH2JS700Q79TREBNBGAU1M/ag_bigpicture.html"

Assign a file to set the percentage of time used for each processing. If you customize your script file, you also need to use a custom distribution file for the test.

Run Time error detected by using IIS Extended Log File
In addition to WCAT, you can also use IIS's extended log feature to discover errors in ASP. You can open the URI_Query extended log file to record ASP errors. By default, this file is not opened. You can follow these steps to open it:

1. Select a Web or FTP site to open its property page.

2. Activate log. Select W3C extended log file format.

3. Click properties.

4. On the extended attributes page, select the domain (in this example, URI_Query) You want to log on ). The time,

Customer IP address, method, URI Stem, and HTTP status.

5. Click application.

Use WCAT to maintain Session data
If you want to use WCAT to maintain ASP Session data, you can use cookies. Add the following line to the top of your script (. scr) test file:

Set Cookie = "<CookieName>"

It doesn't matter what you set the cookie as long as you set it. By setting a cookie, each virtual directory created by WCAT has its own ASPSESSIONID cookie, which provides the ability to maintain the session status. That is to say, WCAT maintains a persistent cookie set for each virtual user. To clear the value of a specific cookie, use the following script:

New request CLEAR_COOKIE

Set Cookie = "<cookie to clear>"

Multiple clear_cookies and Set Cookie indicators can be published in your script to control the cookie life. The only way to construct any cookie request is to encode it in the Set RequestHeader indication. This is useful for testing client applications that do not use the ASP session state.

Simulate mail data with WCAT
In a real Web application, you may find that some data is sometimes sent to a URL. The Web Hing programmer's reference documents provide detailed information about the Web Publishing API that you may use. When using WCAT, you can simulate the delivery of data to a specific URL. To mail data to an ASP form, follow these steps:

◎ Verb = "POST"

◎ RequestHeader = "Content-Type: application/x-www-form-urlencoded \ r \ n"

◎ RequestData = "Field1 = Value1 & Field2 = Value2 & Field3 = Value3 \ r \ n"

New WCAT functions and fixes
In the latest version of WCAT, some new features and bug fixes are added. Includes the following:

1. If no request is made during the test, the log file byte counter will not be damaged.

2. If you have an incomplete redirection, column it as a failed connection.

3. the user name and password can now receive a file name and use the content of the file. Each file can have only one user name-Password pair.

4. Now you can specify a request to test the server.

5. Improved the SSL test. Now you can use the new indication SSL_Protocol to specify the port used for SSL (https) requests. If SSL_Protocol is not specified, WCAT must negotiate with the server to use the best security protocol. Do not use the SSL Provider indication until you fully understand how to use it. This instruction is also removed from the Script Template.

6. the URL can be replaced anywhere in the input file (instead of the header ). Macro replacement reduces performance. However, the performance will not be significantly reduced unless you are replacing large files. Performance degradation only occurs when WCAT passes through each file for the first time. This is in the preparation phase, so if you choose to use the replacement feature, make sure that your preparation phase is long enough to handle this extra job.

In earlier versions of WCAT, regardless of whether or not it is replaced, the performance may be affected due to the use of macros. Now, when we use a dynamic macro and every request changes, this slight effect will still occur.

7. Improved HTTP redirection to support servers, specific port numbers, and security. The MaxRedirects script indicates (it is a DWORD) that you can set the maximum value of redirection. By default, the maximum value is 0, which represents an infinite number of redirects.

Summary
WCAT is only one of the tools available to monitor your IIS server. INetMonitor is a tool used for capacity planning, load monitoring, hardware configuration, and simulation. It is carried by Microsoft BackOffice resource toolkit (version 2) and can be obtained from Microsoft Press. A Brief Introduction to INetMonitor can be seen in the article INetMonitor, a flexible and easy-to-use capacity planning tool.