WCAT – Simple Performance Test Tool for your .NET web app

| Comments

WCAT (Web Capacity Analysis Tool) is a tiny but excellent tool from Microsoft to perform load test your web application on IIS.  This tool enables you to do performance analysis on various scenarios of your web application.  All “perfmon” performance counters (like processor time, private bytes usage,  disk queue length,  total bytes sent or received in network) can be specified for the performance testing.  A performance test is for a business scenario, hence a test needs to include all servers (application server, database server) involved in the business scenario.  This is tool is as handy as possible to perform a load test even on single machine.

Once you specify the scenario in your application (i.e. appropriate URLs), a number of virtual clients from various client machines  will visit the URL with appropriate request data.  Like other performance tools, the following players are involved in a performance testing:

  • Server – machines on which your web application components are running
  • Client – A virtual client on a machine which acts as end-user to visit the URL
  • Controller – This coordinates a test among the virtual clients on various machines.  It also capture and collate the performance counters from appropriate servers.

I’ve created a small ASP.NET MVC3 application with following actions:
* http://localhost/myapp/load/create – to insert a simple “comment” field  value into the database (using POST data COMMENT =  “”)
* http://localhost/myapp/load – to lists all comments

WCAT uses Windows Scripting and you can use JavaScript syntax to define the scenario for your test.  Below is a sample scenario in a file scenario.ubr:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

scenario
 {
 name    = "IIS Home Page";

warmup      = 30;
 duration    = 50;

default
 {
 // send keep-alive header
 setheader
 {
 name    = "Connection";
 value   = "keep-alive";
 }

// set the host header
 setheader
 {
 name    = "Host";
 value   = server();
 }

// HTTP1.1 request
 version     = HTTP11;

// keep the connection alive after the request
 close       = ka;
 }

//
 // This script is made for IIS7
 //
 transaction
 {
 id = "My App Load Test";
 weight = 1;

request
 {
 url = "/myapp/load/create";
 verb = POST;
 postdata = "Comment=Tested";
 statuscode= 200;
 }

request
 {
 url         = "/MyBooks/load";
 statuscode  = 200;
 }

close
 {
 method      = reset;
 }
 }
 }

A scenario file normally contains warmup time (ramp up), test duration, cooldown time (ramp down).  The default section enables you to specify default HTTP headers for the test.  The transaction section is used to specify the actual business scenarios.  The weight property is used to set the priority of this transaction.  The request section is used to specify individual page request in the transaction.  A “request” contains

  • URL of the page
  • Optionally the HTTP verb (default GET).  In case of posting data, you have to specify the POST as verb.
  • POSTDATA for POST
  • Status code which is normally 200, but for some cases you may need to specify 300 or 302 for moving request

The other test details like servers and client machine names,  number of virtual clients, performance counters can be specified to WCAT through another script file called “setting file”.  Below is a sample setting file named “setting.ubr”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

settings
 {
 clientfile     = "scenario.ubr";
 server         = "localhost";
 clients        = 2;
 virtualclients = 10;

counters
 {
 interval = 10;

counter = "Processor(_Total)\\% Processor Time";
 counter = "Processor(_Total)\\% Privileged Time";
 counter = "Processor(_Total)\\% User Time";
 counter = "Processor(_Total)\\Interrupts/sec";

counter = "Memory\\Available KBytes";

counter = "Process(w3wp)\\Working Set";

counter = "System\\Context Switches/sec";
 counter = "System\\System Calls/sec";

counter = "Web Service(_Total)\\Bytes Received/sec" ;
 counter = "Web Service(_Total)\\Bytes Sent/sec" ;
 counter = "Web Service(_Total)\\Connection Attempts/sec" ;
 counter = "Web Service(_Total)\\Get Requests/sec" ;
 }

// other settings
 }

A setting file usually contains the following:

  • The scenario file the clients need to execute
  • Server machines
  • Number of physical client machines for this test
  • Number of virtual clients for this test
  • Performance counters
  • Registry settings

Note that you can use any file extension for scenario and setting files.  I have followed the convention”ubr” is used in WCAT sample.

Initial Setup

  1. Download the tool from http://snip.udooz.net/wcat63.   It has x64 version also.
  2. Add the installed folder path into system PATH.

This setup has following three exeutables and one Windows script file along with documentation and samples folders:

  • wcctl.exe – controller
  • wcclient.exe – client
  • wcutil.exe – small utility to view a brief report of a test
  • wcat.wsf – used to update, terminate and run wcclient on various client machines.

Initially, you need to update WCAT setup on all client machines by

1

wcat.wsf –terminate –update –clients {comma separated list of WCAT client machines}

Steps for the Testing

To perform a test, you need a machine for “controller”, one or more machines for “clients” and the server machines.  You can do the testing even within a single machine by specifying “localhost”.

  1. Once you prepare the scenario and setting files, create a folder  in the controller machine for your test and copy these files on to it.
  2. Open the command prompt as Administrator.
  3. Run wcctl -t scenario.ubr -f settings.ubr -x on the controller machine.  The output will be like

  1. Run wcclient.exe on all client machines.

After the test run, the output in the controller command prompt would be like

After all the test run completed, result will be stored in log.xml file in the controller’s  machine current directory.  WCAT has a XSLT “report.xsl” to transform this XML into readable in its installed folder.  Copy the file into log.xml.  Open the log.xml in the browser to see the output.  A part of log.xml file is

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?xml version='1.0'?>
 <?xml-stylesheet type='text/xsl' href='report.xsl'?>
 <report name="wcat" version="6.4.0" level="1" top="100">
 <section name="header" key="90000">
 ...

<item>
 <data name="counter" >\Processor(_Total)\% Processor Time</data>
 <data name="avg" >1.82</data>
 <data name="min" >1.82</data>
 <data name="max" >1.82</data>
 <data name="delta" >0.00</data>
 <item>
 <data name="time" >0.00</data>
 <data name="current" >1.82</data>
 </item>
 </item>
 <item>
 <data name="counter" >\Process(w3wp)\Private Bytes</data>
 <data name="avg" >98455552.00</data>
 <data name="min" >98455552.00</data>
 <data name="max" >98455552.00</data>
 <data name="delta" >0.00</data>
 <item>
 <data name="time" >0.00</data>
 <data name="current" >98455552.00</data>
 </item>
 </item>
 </table>

...
 </report>

Final Words

WCAT might not help to test an entire application which normally has so many user interaction which are not simply captured by single POST request.  However, it would help to perform load testing on every atomic part of your application or to perform technology evaluation as part of prototype engineering.