Using WCAT for IIS stress testing

using WCAT for IIS stress testingCategory: JavaScript album it informatization 2008-10-13 16:56 5754 people read reviews (1) favorite reports IIS test server Microsoft Scripting Network

How to build up WCAT

Microsoft's Web Capacity Analysis tool (WCAT) is an essential tool for testing your client-server network configuration. This tool simulates a variety of workload scenarios on your network, allowing you to determine the optimal configuration of your network and servers. WCAT is designed to evaluate Internet servers running on Microsoft Windows NT servers and Microsoft Internet Information Server (IIS), but you can use it in almost any type of Web server. However, there is one limitation: ASP and ISAPI do not run on Unix, so they cannot be tested in that environment. This tool has one of the best places to be priced--can be downloaded for free。 The downloaded content includes detailed documentation that is very 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 simulations that allow you to test the download of pages or content from the server at various scales, at different levels of connectivity. A detailed list of these tests can be seen from the documentation. You can use the extensions for ASP, Internet Access application Programming Interface (ISAPI), and Public Gateway Interface (CGI) applications to test server performance. This is useful even if you are not using these extensions now, because you can test the extensions before you configure them. In addition, the WCAT test runs simulations to test the response on the server for lower-level communications, which include cryptographic sockets Layer (SSL) 2.0 and 3.0, Private communication Technology (PCT) 1.0 encryption, and Hypertext Transfer Protocol (HTTP) retention (after the initial request is complete, Allow the connection to be maintained).

If you need more extensive testing, you can create your own custom simulations and run them with WCAT. You can even test those servers that are connected to more than one network and test the use of cookies. You can also use it to test your local network.

How to build up WCAT
Now that you might be eager to see WCAT, let's take a look at the typical setup that needs to be done first before starting the test. To run a WCAT test, you need 4 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 responds to the request with the WCAT file (those files depend on the emulation you are running).

Server

The server's responsibility is to respond to requests for connections, manage connections, receive, process, and respond to requests for web content (that is, Web pages). If you want to install all static file tests, you need to have 220M of space on your hard drive. ASP testing requires less than 110K of space, except for the specific content you want to test, and you don't need to install anything on the server. You must install a TCP/IP and limit it to the network adapter.

On Windows NT, when you set up the server component, the Setup program automatically copies the necessary files to the appropriate location. If you are not running Windows NT, then some of your work must be done on your own. Install the server files and copy those directories that start with perfsize from the WWW root of the Windows NT Server to the server you are going to use. Don't forget to copy the files in these directories as well.

Client

The client is responsible for making the server work hard. To be specific, in a WCAT test, you can configure the client at different levels by specifying the number of client browsers in the test, the size, type, and speed of the client request, the frequency of the request and the requested page, and the duration of the test. You don't have to give every client you want to test. Each WCAT customer test runs within its own program, so that more than one customer can run on each client. These are the so-called virtual customers. Each client can run up to 200 customers, which allows you to test a staggering number of connections with fewer resources (note: Testing 200 physical customers is just an approximation.) 200 physical customers will cause a greater load on the server).

You want to monitor the use of memory on your computer. If the customer is using more than its physical memory (in other words, it is frantically exchanging content), then you will feel a decrease in speed and should reduce the number of virtual customers. Usually, unless your hardware condition is too poor, the customer will not have a problem.

A Windows NT Server or Windows NT Workstation (4.0) must be installed on the client computer, 1M of free space on the hard disk, TCP/IP installed, and restricted to the network adapter.

Controller

The WCAT controller is responsible for managing WCAT tests. This separates the actual tests performed on other machines from the load on the test management. The controller uses input files that specify how to run the tests, when the tests end, and then write the results to the output file.

To run a pre-prepared test, you need to include 3 input files on the controller. If you want to customize the test program, you can use your own version of these files. You need to include a profile that specifies the number of customers, the number of virtual customers, and the duration of the test. The profile extension is. CFG, which is named according to the test that is running. 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 page name requested from the server. The script file extension is. scr, and your script filename should be test1.scr, as in the previous example. The third required input file is the distribution file, which specifies the frequency of customer requests. The extension for this input file is. DST, which is named TEST1.DST in the example above.

There is also an additional optional input file, performance counter file, which can be used to monitor performance monitoring counters on the counter. Its extension is. PFC, in the above example, this file should be named TEST1.PFC.

With the input file, now it's time to say the output file. The controller generates a log file that contains the statistics collected in the test. The log file extension is. log, a comma-delimited text file that can be edited with a text editor, or as input to a spreadsheet or database. If you specify a performance counter as input, the controller will also generate a performance counter result file (with a. prf extension).

A machine that acts as a controller must have a Windows NT Server or a Windows NT Workstation (4.0), 10M of free space on the hard disk, TCP/IP installed, and limited to the network adapter.

Network

The network used for WCAT is just a simple communication connection between your client, server, and controller. The network must use TCP/IP, and the network bandwidth is preferably 100M bits per second. When you build a test, make sure that the network-attached machine is configured correctly so that you know that the performance problem is not caused by improper installation.

Performance and stress testing

To determine the best performance your Web application might achieve, make the following recommendations:

An isolated private network (this is ideal)

Enough customers to unleash the full potential of the server

Full network bandwidth (Mbps or higher)

Multiple network cards to distribute load

A multi-processor machine for scalability testing (this is ideal)

Rerun the test to see if the test results will regenerate

First view the page in a browser to determine the application settings and run correctly

If you want to test the performance of your application under average load, you should set some performance metrics (number of pages per second, CPU usage, response time) and try to reach these metrics.

If your goal is to perform stress testing, then you don't necessarily need a private network and many customers. Placing your application at a moderate load is sufficient to expose the problem; running the controller and a client on the server is sufficient. This is certainly more effective than refreshing the page in a single browser. If you want to do stress testing at a higher level, it's good to use a private network and many customers. Also, running a stress test on a multiprocessor machine is a good way to find a flow problem.


After you have installed the required files on each computer with the Setup program, you should configure the client and controller machines the first time you run WCAT. You need to know the IP address of these machines. By using the ping command line feature of TCP/IP, you can obtain an IP address that corresponds to 4 digits in square brackets (for example, [11.1.38.2]). These numbers represent the IP addresses of the machines on the network.

Configuration

With the IP address, you can configure the client and controller. The WCAT controller is configured at the command line prompt. Just go to the directory that contains the controller (by default, 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.

Configure the client as with the configuration controller. This time, at the command prompt, enter the client's directory and type the config controller name IP address (the controller name refers to the name of the controller machine, and the IP address refers to the client).

Run

There are 5 main steps to running WCAT:

The first step: Start WCAT customers, controllers and servers.

Start the WCAT client on the client by going to the client directory at the prompt, typing the client (this is a batch file, running the program is Wcclient.exe). The program tries to connect to the controller. If the connection is not up, then the program will connect again after 10 seconds and continue to connect every 10 seconds until you terminate the Wcclient.exe operation. To terminate Wcclient.exe, type CTRL + C at the command prompt.

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

Finally, the IIS and HTTP services are started on the server.

Step Two: Prepare

During the preparation phase, the controller sends instructions to the client and the customer starts sending requests to the server. The output is not collected during the prep phase because the server is slower to react than usual (the pages, objects, and instructions that are often used are not cached by the processor).

Step Three: Experiment

During the experimental phase, the controller instructs the client to send a special request to the server and the server responds. Collects statistics and sends status information to the client. The controller monitors the entire process of testing. At this point WCAT is determining the performance of your server based on the workload being emulated. If you have specified that you want to monitor performance counters, the controller monitors these values during the experimental phase.

Fourth Step: Cooling

After all the work is done, it's time to cool down (you don't want your server to cramp, do you?) ）。 During the cooling phase, the controller instructs the client to stop sending requests. Customers end their operations, and while the customer continues to collect statistics, the data is no longer saved for output; Because cooling does not indicate a real workload, these statistics are useless.

Fifth Step: Reporting

During the reporting phase, the customer sends the collected data to the controller. Once all the data has been sent, the controller shuts down the client connection. Be aware that WCAT is still running on your customers, so they will revert to the initial configuration and attempt to connect to the controller. The data collected by the controller is written to a log file. The 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 numbers of pages per customer read. At this point, if you specify that you want to monitor performance counters, this number will be written to the performance results file.

Analysis Results
The information written to the log file includes a file header, results, performance counters (if you specify that you want to include these), files, and class statistics. The header contains general information about the test, such as the date and time the test was run, the input and output files used, and the duration. In the WCAT documentation, there is a detailed information about the header's domain, structure, and an example.

There are many details written to the. log file, the most interesting of which may be the "Read page" table. The first number column is the total number of pages read by all clients. The second column is the rate at which the first client sees the page per second. The third column is the total number of pages that the first client sees. If you have more than one customer, you will continue to see the rate and the total number of each machine behind you.

The result area of the log file is a table that summarizes all the data collected in the test. The data collected includes the number of pages requested, the response time, the connection, and any errors that may be encountered. The format of the table and the construction of each column are in the WCAT document.

If you specify that you want to monitor performance counters, there is a section in the WCAT log detailing the content. This data is also represented in a table that contains the average of each counter in each page.

The file area of the log contains a table with 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 class statistics area, which contains data that represents the rate of page recovery on the customer. Includes the number of pages successfully recovered, the rate of error, and the rate at which a particular type of page (in other words, the class of the page) was requested. You can use this data to determine which type of page is most requested.

using and logging performance counters
As mentioned earlier, you can choose to use WCAT performance counters on Windows NT-based servers. With performance counters, you can measure the use of processors, physical memory, hard disk subsystems, memory buffers, and the performance of the services you use, such as IIS. To use the performance counters, you need to use the-p switch when running the controller, and you need to provide a file with a. pfc extension that specifies the counters you want to monitor. By default, this file is in the/scripts directory of the WCAT controller.

Using SAMPLE.PFC

A sample input file with a performance counter--sample.pfc--is installed in the/scripts directory of the WCAT controller. Each counter that you want to monitor is listed in a separate row, aligned to the left, without tabs. You can add a comment to each line, with a # sign at the beginning of each line. There are up to 50 counters in each file. The syntax for a single line in a 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 a particular example of an object, and counter is the actual property of the object you want to monitor. To monitor the processor time used by the IIS procedure Inetinfo, you can add the following entry 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 determine which objects you can monitor, run the Performance monitoring feature (run Perfmon.exe at the command prompt) and choose the Add to chart item from the Edit menu. You will be prompted with the following dialog box:


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 each counter's meaning.

The following table lists some of the counters:

Object	Count	Comments
Active Server Pages	Allocated memory
	Requests per second	Rate of requests that the ASP satisfies
	Request Execution Time	The average time spent executing a request
	Request Waiting time	The time to wait in the queue for the previous request to execute
	Total number of failed requests
	Number of Requests queued
	Number of requests rejected
	The current session
Process (inetinfo)	Processor Time
	Special time
	User Time
	Private bytes	The total amount of memory used by this process. If this number grows infinitely, it means that something, some place (such as an ISAPI ASP component) is weakened
	Work settings
	Thread Flow counter

Internet Information Services Global	Cache Hit
Memory	Available bytes
	Page faults per second
Web Service (_total)	Bytes Received per second
	Bytes Sent per second
	Current Anonymous user
	Current non-anonymous user
	Current connection
System	Total Processor Time
	Context conversions per second
	System calls per second
Processor (0) (Each processor)	DPC Rate
	Number of interrupts per second
	DPC Queued per second

The results in the performance counters are written to a special result file, TESTNAME.PRF (where TestName is the name of the test). This is a comma-delimited text file that can be read in any standard text editor, or used as input to a spreadsheet or database. However, this file cannot be read directly with Perfmon. This file contains header information (counter number, machine name, named Start time), column header, and a table containing the collected performance data. You can refer to the WCAT documentation for the complete syntax and the use of this file.


Now we are going to introduce you to some WCAT applications.

Write your own WCAT test script
You can customize WCAT running scenarios by specifying different command-line switches, modifying server and client configurations, using your own ASP, ISAPI, or CGI scripts, and changing the input files for 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 allocation (. DST) files as needed.

By default, the configuration file is located in the controller's/webctrl directory. The information in this file contains the number of buffers used in the test, the number of clients to use, the number of streams to use, and the duration of the test.

To determine the scripts you need to run your tests, you can modify the script files. In this file, you can specify the specific ASP you want to test, as well as the ISAPI and CGI extensions. The following is a sample script document in the WCAT documentation.

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

#

# Test script file for WCAT

#

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

# Format of Script specification:

#

# ClassId Operation Files

# note:operation Strings is case insensitive

#

# Plaza Welcome page = >

NEW TRANSACTION

ClassId = 1

NEW REQUEST HTTP

Verb = "GET"

URL = "/scripts/welcome.py"

# Click Repeat shopper = > Plaza Lobby

NEW TRANSACTION

ClassId = 2

NEW REQUEST HTTP

Verb = "GET"

URL = "/prd.i/pgen/plaza/jq04q9jf66sh2js700q79trebnbgau1m/plaza1.html"

# Click AG = > AG Lobby

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"

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

using IIS extended log files to discover run time errors
In addition to using WCAT, you can also use the Extended Logging feature of IIS to discover errors in ASP. You can open the Uri_query extension log file to record ASP errors. By default, this file is not open. The technique of opening it has the following steps:

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

2, activate the log, select the expansion log file format.

3. Click Properties.

4. On the Extended Properties page, select the domain (in this example, uri_query) that you want to log into the journal. By default, the time is activated,

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

5. Click Apply.

maintain session data with WCAT
If you want to use WCAT to maintain ASP session data, you can use cookies. Add such a line at the top of your script (. scr) test file:

Set cookie= "< CookieName >"

It doesn't matter what you set the cookie to, as long as you set it up. By setting a cookie, each virtual directory created by WCAT has its own ASPSessionID cookie, which provides the ability to maintain session state. This means that WCAT maintains a persistent cookie collection for each virtual user. To clear the value of a particular cookie, you can use the following script:

NEW REQUEST Clear_cookie

Set cookie = "< cookie to clear >"

Multiple Clear_cookie and set cookie instructions can be published in your script to control the lifetime of the cookie. The only way to make any cookie request is to encode it in the set Requestheader indicator. This is useful for testing client applications that do not use the ASP session state.

using WCAT to simulate the mailing data
In a real Web application, you'll find that sometimes you need to post some data to a URL. The Web publishing Programmer's Reference provides details of the Web publishing API you might be using. When using WCAT, you can simulate sending data to a specific URL. To post data to an ASP form, you have the following steps:

Verb = "POST"

Requestheader = "content-type:application/x-www-form-urlencoded/r/n"

RequestData = "field1=value1&field2=value2&field3=value3/r/n"

New WCAT function and repair
In the latest version of WCAT, some new features and bug fixes have been added. Includes the following content:

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

2. If you have a redirect that cannot be completed, list it now as a failed connection.

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

4. It is now possible to specify a request to test the server.

5, improved the SSL test. You can now specify the port to use for SSL (HTTPS) requests with the new instruction Ssl_protocol. If Ssl_protocol is not specified, then WCAT will negotiate with the server to use the best security protocol. Do not use the SSL provider instructions until you fully understand how to use it. The use of this instruction is also canceled in the script template.

6. URLs can now be replaced anywhere in the input file (not just in the head). Performance is degraded by the use of macro substitution. But the performance will not be much lower unless you are replacing it with large files. The decrease in performance will only occur when WCAT is first passed through each file. This is the preparation phase, so if you choose to use the Replace function, make sure that your preparation stage is long enough to handle this extra work.

In previous versions of WCAT, performance had been affected by the use of macros, regardless of whether replacements were used. This slight impact can now occur when using dynamic macros that vary from one request to the other.

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

Summary
WCAT is just one of the tools available to monitor your IIS server. The InetMonitor is a tool for capacity planning, load monitoring, hardware configuration, and simulation. It is carried by the Microsoft BackOffice Resource Kit (second edition) and can be obtained from Microsoft Press. A brief introduction to the InetMonitor can beflexible and easy-to-use capacity planning tools InetMonitorSeen in the article.

Using WCAT for IIS stress testing