Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / Javascript

WCAT – Simple Performance Test Tool for your .NET Web App

0.00/5 (No votes)
16 Sep 2011CC (ASA 2.5)4 min read 44.3K  
WCAT – Simple Performance Test Tool for your .NET web app

WCAT (Web Capacity Analysis Tool) is a tiny but excellent tool from Microsoft to perform load test on 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 a 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 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 captures and collates the performance counters from appropriate servers.

I’ve created a small ASP.NET MVC3 application with the following actions:
* http://localhost/myapp/load/create – to insert a simple “comment” field value into the database (using POST data COMMENT = “<value>”)
* 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:

JavaScript
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”:

JavaScript
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 the following three executables 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:

Bash
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:

    Image 1

  4. Run wcclient.exe on all client machines.

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

    Image 2

After all the test run is complete, results 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:

XML
<?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 interactions which are not simply captured by a 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.

License

This article, along with any associated source code and files, is licensed under The Creative Commons Attribution-ShareAlike 2.5 License