Dan Watsons Coding Zen

I needed to stress test the current open source project I am working on (Tribe.Cache – Dictionary Cache) under heavy load. I decided that to do this I would put together a simple ASP.NET MVC site that would get a new instance of an object and then insert it into the cache or alternatively read from the stale object from the cache dependant on the cache items expiration.  I setup my simple site under IIS7….. But now I needed to throw thousands of HTTP requests at the site in order to see how the cache and application would behave and perform under heavy load.

In able to do this I decided to use Microsoft's IIS Resources kit which can be downloaded from here. Once you have installed the IIS Resources kit you will now need to make some configuration changes to enable you to test the performance of your site.
The first thing I did was to open up perfmon (Performance Monitor) which you can do my typing “perfmon.msc” from the command line.
You will then need to tell perfmon to monitor all GET requests on your local IIS Server where you have hosted your web application.

To enable monitoring of the “GET” requests right click next to the graph and choose Add Counters.

Now find the Web Service heading from the left hand upper panel and add Get Requests/sec to your “Added counters” then click ok to finish.

 

Now perfmon will be monitoring all “GET” requests that reach your IIS server and this information will be displayed in the perfmon graph.
In able to run WCAT which is installed with the IIS Resource Kit you will need to make some changes to the WCAT configuration files.
Firstly browse to the directory where WCAT is installed (probably something like C:\Program Files (x86)\IIS Resources\WCAT Controller or C:\Program Files\IIS Resources\WCAT Controller). There are three configuration files are needed to run the performance test. These configuration files should be located in the WCAT Controller directory if they are not just create them.

Configuration.cfg – This is a general configuration file.

WarmupTime		5s
            NumClientMachines	         1
            MaxRecvBuffer		64K
            CooldownTime		10s
            ThinkTime		         1
            NumClientThreads	         100
            Duration		         20s
            Comment			512 byte keep-alive

Script.cfg – defines the requests to make. (Please note you can have more than one transaction in this file but you will then need to inform Distribution.cfg how to distribute them)
 

NEW TRANSACTION
            	classId = 1
            	NEW REQUEST HTTP
            	verb = "GET"
            	url = http://localhost/Home/Index

Distribution.cfg – Distributes the requests in the Script.cfg – so in this example it shows that the transaction with classId 1 is used for 100% of the requests. If you had multiple transactions in Script.cfg you can split their distribution by percentage.
  

1 100

Now from the command line you will need to call the wcclient.exe which is located in the WCAT Client folder (not the WCAT Controller folder) and tell it wait for connections on localhost.
 

"C:\Program Files (x86)\IIS Resources\WCAT Client\wcclient.exe" localhost

After the wcclient.exe is waiting to accept connections then from the command line you will need to call the wcctl.exe which is in the WCAT Controller folder passing in the location of the configuration files you have made / edited.
 

"C:\Program Files (x86)\IIS Resources\WCAT Controller\wcctl" -a localhost -c configuration.cfg -s script.cfg -d Distribution.cfg

After you have execution of the performance test has finished you will see summary information.

Also if you go back to perfmon you will see the requests hitting your server (please note you may need to change the graph scale which can be done by right clicking next to the graph and selecting Properties –> Graph –> Scale).

I found it useful to enable logging with log4net to see what errors / issues your application may encounter under heavy lead. I personally found it surprising that I had 100% unit test coverage but the application still threw errors under heavy load!  It just goes to show that unit tests do not catch everything!