Building ASP.NET web applications? Plan to serve thousands of users? Would you like to see how your application would behave [misbehave] under stress?

Use simple-to-use and freely available WCAT tool to generate the load and get detailed report for expected throughput (requests/sec) and other important performance-wise information.

Summary of steps

• Install WCAT
• Create configuration files
• Run the test
• Examine results

Next section describes each step in details. Note, this post is a how-to, a jump start - not the guidelines or best practices of how to use the tool.

Install WCAT

Download and install Internet Information Services (IIS) 6.0 Resource Kit Tools. For the purpose of our exercise there is no need to install all the tools included with the resources kit, only WCAT.

Create configuration files

There are three textual files one needs to create and configure (you can give any name and extension of your choice):

• script.txt - this file defines the requests, in other words what pages to request and how to request it. Following is an example of simple script.txt file:

NEW TRANSACTION
    classId = 1
    NEW REQUEST HTTP
        Verb = "GET"
        URL = "http://localhost/BankingShmanking/Default.aspx"

• distribution.txt - defines weights among different requests. For example, if I need to generate request to page1.aspx twice as to page2.aspx, I will define it in this file. In case of loading only one page, the file is meaningless. Following is an example of simple distribution.txt file (1 refers to classId in script.txt file, and 50 is that 50% of the load should got this file which is meaningless since there is only one page to request, thus it will get the whole 100% load):

1 50

• config.txt - determines the duration of the test, number of clients that will generate the requests against the web application. Following is the example of simple config.txt file:

Warmuptime 5s
Duration 30s
CooldownTime 5s
NumClientMachines 1
NumClientThreads 20

Save the files in "C:\Program Files\IIS Resources\WCAT Controller" folder.

Run the test

To run the stress test open command prompt by opening Run window(Windows + R) type cmd and hit Enter. Change current directory to "C:\Program Files\IIS Resources\WCAT Controller>" and run the following command to test the page hosted on the localhost:

wcctl -c config.txt -d distribution.txt -s script.txt -a localhost

then open second command prompt, change current folder to "C:\Program Files\IIS Resources\WCAT Client" and run the following command to actually launch the virtual client's requests from local machine:

wcclient.exe localhost

Examine results

The results are displayed interactively in the command line windows

The tool also generates log file that includes logged metrics - look for it in "C:\Program Files\IIS Resources\WCAT Controller" folder.

WCAT tool is actively developed by IIS team and recently they released new version of the tool - WCAT 6.3, download it from here, free.

Related Books

• Ultra-Fast ASP.NET: Build Ultra-Fast and Ultra-Scalable web sites using ASP.NET and SQL Server
• Advanced .NET Debugging
• Debugging Microsoft .NET 2.0 Applications

Related materials

• This post was mainly based on this article - IIS 7.0 Output Caching
• WCAT: Easy, Magical, Stress Testing for IIS Web Applications
• WCat 6.3 (x86)

My related posts

• Performance Testing For The Masses
• How To Keep ASP.NET ViewState On The Server – Revised
• Identify ASP.NET, Web Services, And WCF Performance Issues By Examining IIS Logs
• patterns & practices Performance Testing Guidance for Web Applications - Final Cut
• Use Performance Counters Templates To Streamline Performance Analysis
• Performance Testing Objectives Document Template

Revealing clear text passwords in memory seems to be a trivial task. This post describes how to reveal clear text passwords and what countermeasures to apply.

Summary of steps:

• Install WinDbg
• Attach to process or open dump file
• Load SOS .Net extensions for WinDbg
• Enumerate threads
• Enumerate objects in thread
• Dump object's values
• Countermeasures and guidelines

Install WinDbg

Download and install WinDbg as described in How to install Windbg and get your first memory dump.

Attach to process or open dump file

WinDbg can analyze both running processes and memory dumps which conveniently can be taken offsite for further investigation. I've created simple console application that accepts user name and password pair as its parameters and stores in local variables in memory:

static void Main(string[] args)
{
    string userName = Console.ReadLine();
    string password = Console.ReadLine();

    Console.ReadLine();
}

Compile and run the application. I called it SecretsInMemory. This is how it looks when running:

Attach WinDbg to the running application by opening File->Attach to a Process:

and press Ok.

Alternatively, we can create dump file - for detailed how-to refer to How to install Windbg and get your first memory dump.

To Investigate resulting dump file in WinDbg open File->Open Crash Dump

Load SOS .Net extensions for WinDbg

To analyze .Net assemblies we need to load .Net extensions by typing .load sos and hitting Enter:

Enumerate threads

Run !threads command to enlist available threads:

and then choose specific thread - use left most column for thread identification as follows ~[thread number goes here]s:

Enumerate objects in thread

Use !dso command to dump all objects in the thread:

Dump object's values

Use !do <object address> to dump specific object's values. Object address is a second column in the list generated by !dso command, the column named "Object" - just copy and paste it:

The password is revealed either by attaching to the process or analyzing a crash file that was taken offsite.

Countermeasures and guidelines

As rule of thumb avoid using custom built identification and authentication mechanisms and leverage those that the infrastructure offers - preferably Windows Integrated authentication. In case where all options exhausted and there is no other way but accept end user credentials, refer to the following article - Using Credential Management in Windows XP and Windows Server 2003. Techniques described in the article allow to leverage built in mechanism of accepting credentials from end user in more secure manner. It also keeps common familiar look and feel across custom application and built in Windows mechanisms leaving less room for end user confusion.

My related posts:

• Authentication Hub

Other resources:

• This post is inspired by Getting started with windbg - part I
• Getting started with windbg - part II
• WinDbg + SOS Cheat Sheet
• ASP.NET 2.0 Security Questions and Answers - Sensitive Data
• ASP.NET 2.0 Security Questions and Answers - Authentication

I just could not hold it back - it is midnight and I am watching Richard Turner's screencast - New Screencast: How to configure IIS7 for Windows CardSpace sites

It was humiliatingly :) easy to set up test server cert, so I've done it, here is the prove:

Next he talks about how to configure it for CardSpace - I stopped watching since I know if I continue I may end up watching the sun set together with my laptop.

Richard, good job!!

Good night.