The Web Application Stress Tool

We used the Web Application Stress (WAS) tool extensively when creating and testing our sample clusters for functionality, performance, load balancing adjustment, and monitor testing. Because this tool realistically simulates multiple browsers requesting pages from a Web application, you can gather meaningful performance metrics.

You can create the scripts that the WAS tool uses in several ways: manually, by recording browser activity, by pointing to an IIS log file, by pointing to the content tree, or by importing a script. The many benefits of using Web Application Stress include:

• Using multiple user names and passwords to gain access to test sites that use the most common forms of authentication and encryption including Distributed Password Authentication (DPA), NTLM, and SSL.
• Support for dynamic cookies that maintain a relationship with the WAS clients, which enables realistic personalized test scenarios and session support.
• Running a test script by using any number of clients, all of which can be controlled from a single centralized WAS manager.
• Configurable bandwidth throttling to simulate modem throughput.
• A custom query-string editor that allows you to save name-value pair combinations as templates and then use these templates across multiple tests.
• Providing summary reports with extensive performance data, including percentiles that remove outliers. In addition to the performance data gathered by the test targets, WAS allows you to specify performance counters that you run against the targets, which can be used to provide a validity check on performance data.
• Support for page groups, which allows you to logically group files and control script flow execution.
• Configuration of time delays between requests (socket level) and script item requests, which enables you to produce exact time sequences for testing trace conditions.

Figure 10.2 shows the configuration options that are available in WAS. (Note: The last option, which is not fully visible, is Name resolution. You can enable this option so that network lookups on remote clients are supported.)

Figure 10.2 The WAS tool configuration window

In addition to the configuration options shown in Figure 10.2, you can configure individual pages that are used in your test scripts. Table 10.9 summarizes the main configuration settings that you can use at the page level.

Table 10.9 Page-Level WAS Configuration Options

Setting	Description
HTTP Verb	Specify the GET, POST, HEAD, or PUT method for handling the page.
Querystring	Specify formatting; provide name, distribution, and value. Import ASP or HTML fields.
Post data	Specify custom POST data in text or binary format.
Custom headers	Use default header information or provide custom HTTP headers. Headers can be static or dynamic.
SSL	Enable SSL for a page.
Remote Data Services (RDS)	Enable Remote Data Services (RDS) and convert query to RDS format.

Figure 10.3 shows the WAS reporting interface and the sample report that was generated after we ran one of our test scripts against a test cluster consisting of two Web servers.

Figure 10.3 Performance data generated by the WAS tool

NOTE

---

If you want to test loads for clients that are running the Microsoft Win32 API, download the Windows DNA Performance Kit Beta from http://www.microsoft.com/com/resources/windnaperf.asp.

Using WAS to Test NLB Web Clusters

Because a WAS stress test uses a small, limited set of client IP addresses and ports, the Network Load Balancing (NLB) assumption of wide distribution in client numbers is invalidated. As a result, you may observe uneven traffic across the cluster.

The following factors will affect the distribution of traffic in WAS testing for an NLB cluster:

• Load balancing affinity—For best results, the cluster should be configured for No affinity. If Single IP or Class C affinity is used, be sure to use several WAS clients, with different Class C addresses in the latter case. No affinity is often the most practical choice.
• The number of WAS clients—Each WAS client uses a single IP address for all HTTP connections. The more clients that are used, the more diversity there is in client IP numbers.

  NOTE

  ---

  Adding multiple IP addresses to a single client will not affect WAS behavior because only one IP is ever used per computer.

  At the socket level, WAS uses an implicit bind when making a request. This means that the operating system supplies the client IP address and port. Microsoft Windows NT behavior is to always provide the interface address from its routing table. This interface address is unique, so adding additional IP addresses to a network adapter does not provide more diversity to the WAS client address space.

• HTTP keep-alives—When HTTP keep-alives are enabled, all items in a page group are requested over a single socket. Because this socket uses a common IP address and client port, NLB sends all requests in that page group to the same Web server. Disabling keep-alives forces a different client port for each item in the page group. This means that each item can be served from a different Web server.

  NOTE

  ---

  With Single or Class C affinity, the keep-alive feature will not affect load balancing. Disabling keep-alives applies only to the No affinity setting.

  Windows NT uses incremental local port numbers in the 1500 through 4000 range, looping back to 1500 after exceeding the upper boundary. This provides excellent diversity in port numbers; however, keep-alives must be avoided in order for large page groups to take advantage of this.