Reality sat in when I, along with Wade Hilmo & Alexis Eller, headed to Europe for the first ever IIS tour. The Web Administration Summit hit 10 countries in just about 4 to 5 weeks and was a absolute awesome experience, with a privilege to interact with so many of our talented customers. The real thanks goes to Eric Woersching (IIS Product Manager) and Olga Londer (IT Pro Evangelism Manager) for putting this awesome experience together.
Lets cut to the chase - the beauty of this trip is that I learned that our hard work in over here (i.e. Redmond, Wa) doesn't always travel. There are flights and ships, but nonetheless, no one seems to carry the message pver the big pond. I hope to help change this small, very small technology problem for IIS customers and find a sufficient, reliable carrier for our message. UPS or FedEx, you game? Yes, I purposely left out United States Postal Service because of my "requirement" of reliable...Sorry postal folks, truth hurts!
In this trip, Wade, Alexis and I used a number of cool tools that the right side of the pond (i.e. Atlantic) hadn't heard of. The kudo's goes to Netherlands for rocking the house and having the "best" in class in the tools "whereabouts" category...
During the trip, several customers asked for my scripts or tools that I used. This is the purpose of tonights post is to help deliver on my promises - todays focus: WCAT.
The biggest complaint I have about WCAT, oh legal name is Web Capacity Analysis Tool, is the fact that out of the box it seems more complicated than it is. This is caused by the fact that there is this Controller piece and this Client. It isn't as complicated as it seems as logistically I just draw a similarity to the 'ole Mainframe world of a dummy client and smart server. It (WCat) is built on this principle.
The Controller, wcctl.exe, is the "brain" or the smart server. It is responsible for telling the configurable # of clients what the heck they are supposed to do. That is to say, wcclient.exe doesn't have the first clue unless the controller sends 'em instructions. This is done by specifying that the controller load a particular UBR file. Yeah, UBR... Sounds like Fubar.
As we mentioned, clients are nothing more than just a "dummy" doing what the "master" (wcctl.exe) tells it what to do. Thus, all the requests that this client will make are completely dependent on the UBR settings.
Wcclient isn't fancy, just a .exe that you must call to start a client. Based on your UBR configuration, the client will "simulate" a number of clients like setting the Client Threads to 80 equals 80 virtual clients.
The beauty of WCAT is that it can simulate a large number of clients and create very quick web traffic against your web server. The downside is it doesn't have any built-in logic to determine what constitutues a "complete" request such as requests for images, htm, css's, and many other files that make up a typical web request. See HTTP RFC for more details...
Using Log Parser to Generate a UBR File
Knowing what we know above, we first think "sheesh, if it can't re-create load already hitting my application then it is useless." I would agree if it wasn't for a very cool tool called Log Parser (all you roadshow attendees you should be very familiar with this awesome tool!) that allows Log Parser to read your IIS Log Files and re-create that traffic against your server. Did we just say that you can easily "re-create" your traffic? You betcha... and free!
Log Parser: Get The Coolness Here
To understand how to do this, I suggest that you review the following:
Simplify your life...
During our trip, I used WCAT 5.2 in a couple of presentations. The first, Managing IIS 6.0 in the Enterprise, where I showed how to use the Trace Diagnostics 1.0 (part of the IIS Diagnostics Toolkit) to view currently executing requests. I simply created a simple UBR that would call an ISAPI filter that simulated a long running request, convienantly called "sleeper.dll." My UBR file looked like the following:
Comment Make a Hang Occur
classid = 2000000
weight = 100
NEW REQUEST HTTP
URL = http://sitename/sleeper.dll?20000
In my case, I made my life simple (for all y'all in attendence) by making an easier command to issue. In this case, I created a couple of easy CMD files called the following:
CONTROLLER.CMDtitle WCAT Controller
wcctl -z %1 -a [HostName]
At this point, life is pretty easy especially if you have multiple scenarios to test. In this case, I issue a couple of simple commands (in this case, on the same machine) to initiate the load against my web application:
title WCAT Client
WCAT is useful, needed free tool that allows a IT Admin or Developer ensure that an application performs as expected, especially under load. Because I am passionate about IT Professionals and their ability to do their jobs (with sometimes little help from developers), I fight with folks all the time saying: Test, Test, and Test again. Developers are never completely sure what "load" is really occuring on the server, IT Pros are! Use your IIS logs, your tools (like Log Parser or a paid log parsing application) tell the story. WCat can be one of them...