MS web application stress tutorial

Installing was

Copy setup. EXE to each client machine. double click on this executable to start the installation. follow the Setup Wizard to complete the install. do not install was on your web server, as this may affect the performance of the server being tested.

Using the was sample script

After installing and opening was for the first time, a script is created calledSample script. Use this script to get a feel for some of the features in the was web stress tool. the actual files used in the sample script are stored in the folder where you installed was. copy the 'wassamples' folder to the root directory of your web site before continuing with this tutorial.

Script View, script items, and script item Detail View

The left hand window of was is known as the Script View. this view displays all of the scripts stored in the current was database. if this is a new database then the only items you see in the script view areUltsAndSample script.

There are seven script items in the sample script. each script item utilizes a special feature of was. for example, notice that one of the script items is a post. using your mouse, highlight the row header to the left of the Post Script item, then double-click. this opens the script item Details View. from this view you can edit the querystring name-value pairs, change post data, modify the header, and enable Secure Socket Layer.

See full-sized image.

Take a look at the querystring Tab View. notice that the namesUserAndPasswordAre being passed in the querystring. also notice that% Username %And% Password %Are the values being passed. these are not literal values, they are special variables that tell was to pass the next available user and next available password from the list. was automatically cycles through the user names and passwords, passing the next set with each post. see below for more information on was users.

Close the script item Details View by clicking the OK button.

Page groups

The last two script items in the sample script contain the text 'adgrp 'underGroupColumn. this is a page group. A page group is shown as 'default' unless you change it. page groups are used to reorganize the order in which the script items are invoked. it is also used to change the number of times that each script item is invoked while a script is running.

You can see a list of all the page groups by selectingPage groupsNode in the script Tree View. you may also change the distribution percentages from this view. notice that keep-alives are enabled for entire page groups at a time. for more in-depth discussion of page groups in Microsoft was, see the following Knowledge Base Article: using page groups.

See full-sized image.

Performance counters

SelectPerf countersNode from the script tree and click onAdd counterButton. It may take a moment or so to load the Add counters dialog when this button is clicked for the first time. Add the following counters:

•	Web Service: GET requests/sec
•	Web Service: POST requests/sec
•	System: % Total processor time
•	Active Server Pages: requests/sec

ChangeCollection IntervalTo every 5 seconds. capturing the correct performance monitor Counters is critical to obtaining the correct data to analyze when the test completes. there are several important performance monitor counters to choose from, based on the type of application you are testing. click here to view a list of the most common web related counters and an explanation of each.

See full-sized image.

Settings

SelectSettingsNode and changeTest Run TimeTo 1 minute, down from 15. leave the other settings as they are for the time being but look over the other options in this view to get an idea of what can be configured for a script. you may also set the default settings for all new scripts by selectingUltsNode and changing those options. Keep in mind that the settings in the defaults node will not affect existing scripts, such as the sample script.

See full-sized image.

Users

SelectUsersNode and double-click on the default user population, indicated by the following icon:

This opens the users view where you can add and delete users from the default population and create new populations. each was user stores cookie information and authentication data. notice that there are 20 users in the default population.

Was users are not the sameStress Level (threads), A setting located in the concurrent connections section of the settings node. The two concepts shocould be kept separate.

Clients

SelectScriptsFromViewMenu to return to the Script View. SelectClientsNode under the sample script and double-click on the default client group, indicated by the following icon:

This opens the clients view where you can add and delete client machines from the current group or add new groups of client machines. notice that 'localhost' is the only client and that it has a check box next to it. this means that the current machine is acting as a was client. leave the client view as is and selectScriptsFromViewMenu to return to the Script View.

For more in-depth discussion of users and clients in Microsoft was, see the following Knowledge Base Article: Understanding threads, users, and clients.

Running a test

Once you have created a script and configured all the settings, users, and clients, it is time to start the test. Select the sample script and chooseRunFormScriptsMenu. Allow the test to complete.

Reporting

SelectReportsFromViewMenu to open the reports view. expand the sample script report to display all of the Report nodes. there shoshould be at least one node who's title is the date and time in which your latest test was started. expand and select the top level of this report node to view a summary of this test.

See full-sized image.

You can select a specific node of the report tree to view more in-depth information. For example, selectResult CodesNode to display a sum of the HTTP result codes for every request in the test. ExpandingPerf countersNode displays the counters that have been collected during the test.

ExpandPage dataNode and select the first script item. the right hand pane displays detailed information regarding this script item. reports provide the response time for specific pages by determining when the script has finished downloading on the client. this is a good source of performance data.

The time to first byte (ttfb) calculates the time from the request for the page until was since es the first byte of data, in milliseconds. the time to last byte (TTLB) calculates the total time from the request until the last byte of data has been received ed on the client, in milliseconds. this number includes des the ttfb time and any additional time needed to receive the last byte of data. all of the requests are sorted, then the data is divided into percentiles. for a more in-depth discussion of the P-squared algorithm and percentiles, see the following was Knowledge Base Article: percentiles in was.

While in report view, you can selectExport to CSVFromFileMenu. exporting the report values to a format that Microsoft Excel can read allows you to create charts that show where most of the requests fall. For example, the following chart has strates time to last byte:

 

See full-sized image.

General guidelines for using was

•	As a rule, use between 10 and 100 threads. you will rarely have a need to run a stress test that requires more than 100 threads per client machine. be sure to monitor the processor utilization on the clients. anything below 80% shocould be OK. the client machine (s) may not be capable of sustaining the stress loads where the processor utilization is greater than 80%, at which point the test will become invalid.
•	When adjusting the threads and sockets for a was stress test, use just one socket (stress multiplier) unless you are using Ming a special type of test. see the online help topic "stress level. stress multiplier "if you require more information on this setting.
•	Limit the number of users to less than 1,000 unless there is a specific reason that you require more unique users. although the number of users allowable is only limited by the amount of memory on the client machine, you may find that it takes too long for a test to initialize when using a large number of users.
•	Avoid creating scripts with more than 1000 script items. the number of scripts is only limited by the amount of memory on the client machine but you may find that it takes too long for a test to initialize when using a large number of script items.

Web Testing Overview

To use the was web stress tool to it's fullest potential, you'll need a general understanding of Web testing methodology. The following discussion touches on several of the key areas of this field.

Web Testing is divided into three main categories:

•	Performance Testing
•	Stability or stress testing
•	Capacity Planning

The first task in performance testing is to use a tool to apply stress to the web site and measure the maximum requests per second that the Web server can handle. this is a quantitative measurement. the second task is to determine which resource prevents the requests per second from going higher, such as CPU, memory, or backend dependencies. this second task is more of an art than a measurement.

In many situations, the web server processor is the bottleneck. increase the stress to the point where the requests per second start to decrease, then back the stress off slightly. this is the maximum performance that the Web site can be achieve. increasing the stress is accomplished by increasing the stress level (threads) setting. increasing the number of was client machines will also produce a greater stress level.

On the web server, use performance monitor to watch the "System: % Total processor time" and "Web Service: connection attempts/sec" as well as "Active Server Pages: requests queued "counters. if the processors are running at 80 to 85%, then they are most likely the bottleneck. if the requests queued fluctuate considerably during the stress and the processor utilization remains relatively low, this is an indication that the script is calling a server COM component that is processing more callthan it handle. in this case, the server COM component is the bottleneck.

It is a good idea to have an expected peak load that meets your business needs and then create a test that uses enough threads to reach that capacity. this will help you determine the maximum request rate for the Web application and confirm that it is in line with the expected peak load.

The amount of personalization in a web application also plays a significant role in how it performs. was contains several features that make testing a personalized Web site easy. for example you can create users, which allows was to save a cookie with each. you can also use the querystring editor to help create and store several sets of name-value pairs that are passed with each request.

Common web testing problems

1.	Invalid test platform. doesn' t match production servers.
2.	Invalid script. doesn' t accurately simulate production request behavior.
3.	Thread safety issues with unstable server COM components.
4.	Active Server Page script errors and Global. Asa issues.
5.	Insufficient Processor power and/or scripts are too complex for the hardware.