Quick Resource Box

• How to upload a file in a Web test
• Shai Raiten’s blog
• Fiddler
• Performance Testing Guidance How-To's
• Custom Extraction Rule

The technique described in the post exploits fantastic Custom Extraction Rule extensibility options in Visual Studio 2008. It also proves once more endless usefulness of Fiddler.

The Challenge – Web Test Does Not Record File Upload

Our main scenario required to upload files to the web server. Quick search on the web revealed Ed Glas’ post How to upload a file in a Web test. The future looked great. When we followed the steps outlined in the post our Web Test kept failing in recording the file to be uploaded preventing the automation of the load test.

After quick research we identified the difference in our situation – the form was submitted by JavaScript’s Form.Submit(). That is why Visual Studio wasn’t able to record it. We used Fiddler – it captured everything just fine. Next was to save Fiddler’s capture as Visual Studio Web Test:

and then add the Web Test to the solution in Visual Studio (right click on the Project in Solution Explorer-> Add-> Existing Item…).

Creating Custom Extract Rule

When we inspected the capture in Visual Studio we observed the following String Body header that actually was the uploaded file’s contents:

We decided to create custom Extraction Rule that would first extract the user name – the name of the files included user name – and based on it look up related file, then read its contents into context parameter. Later on we used the context parameter to dynamically add the file contents to the request:

The rule itself looked similar to this:

public class FileContentExtractorData : ExtractionRule

{
    private const string Folder = @\\YOUR FILE PATH GOES HERE;
    public string UserName { get; set; }
    private const int Len = 9;

    public override void Extract(object sender,
                                 ExtractionEventArgs e)
    {
        if (e.Response.HtmlDocument != null)
        {
            //USER NAME WAS PART OF THE FILE NAME
            string file_path = Folder + FullName(UserName) + ".txt";
            e.WebTest.Context.Add(this.ContextParameterName,    
            File.OpenText(file_path).ReadToEnd());
        }
    }
    //WELL KNOWN FEATURE BY DESIGN, VS REMOVES
    //LOOK FOR ‘Leading zeroes dropped from datasrouces
    //values bound to a CSV file’
    //IN Performance Testing Guidance How-To's
    //LEADING ZEROS BUT WE NEEDED THEN ALL
    public string FullName(string name)
    {
        if (name.Length < Len)
        {
            StringBuilder new_name = new StringBuilder(Len);
            int delta = Len - name.Length;
            for (int i = 0; i < delta; i++)
                new_name.Append("0");    
            new_name.Append(name);
            return new_name.ToString();
        }
        else
            return name;
    }
}

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

Quick Resource Box

• Sysinternals ProcMon New & Improved – Captures Both System & Application Events
• DebugView - Free Simple Tool To Quickly Identify Performance Problems
• Process Monitor
• DebugView

The other downside is some instrumentation implementations are based on heavyweight logging that introduces even more performance problems.

In this post I am sharing my simple techniques I was using for tracing ASP.NET applications without heavy weight coding and without affecting performance significantly. It produced results relatively quick – we were able to put our fingers on the root cause for slowly performing functions relatively quick.

Instrument with System.Diagnostics.Trace

I am using simple class to report function Entry and Exit using System.Diagnostics.Trace class similar to this [I am sure you can prettify it even more]:

namespace Instrumentation
{
    public class Tracing
    {
        public static void TraceFunctionEnter()
        {
            StackTrace st = new StackTrace();
            System.Diagnostics.Trace.WriteLine(true, "TRC: ENTERING: " + st.GetFrame(1).GetMethod() + "USER:" + System.Web.HttpContext.Current.User.Identity.Name);
        }
        public static void TraceFunctionExit()
        {
            CheckAndFixDefaultListener();
            StackTrace st = new StackTrace();
            Trace.WriteLineIf(true, "TRC: EXITING: " + st.GetFrame(1).GetMethod() + "USER:" + System.Web.HttpContext.Current.User.Identity.Name);
        }
        public static void CheckAndFixDefaultListener()
        {
            DefaultTraceListener dtl = null; 
            TraceListenerCollection listeners = System.Diagnostics.Trace.Listeners;

            if (listeners.Count == 0)
            {
                dtl = new DefaultTraceListener();
                Trace.Listeners.Add(dtl);
                return;
            }
            foreach (TraceListener listener in listeners)
            {
                string listenerType = listener.ToString();
                if ((string.Compare(listenerType, "System.Diagnostics.DefaultTraceListener", true) == 0))
                {
                    return;
                }
            }
            dtl = new DefaultTraceListener();
            Trace.Listeners.Add(dtl);
        }
    }
}

Next is simply calling on static methods when entering and exiting the functions:

protected void Button1_Click(object sender, EventArgs e)
{
    Instrumentation.Tracing.TraceFunctionEnter();
    //DO STUFF
    System.Threading.Thread.Sleep(3000);
    Instrumentation.Tracing.TraceFunctionExit();
}

Collecting Instrumentation Information

Until recently I was using freely available Sysinternals DebugView. Here is how instrumented code would look in DebugView:

Even though I have not reported timestamps, DebugView have it’s own stop watch and shows the timestamps precisely.

Recently I discovered new and improved [freely available] Procmon that is able to capture System.Diagnostics.Trace events alongside with system events, so I next time I am on assignment I’d probably use Procmon :).

Conclusion and Recommendations

The techniques I have outlined in this post does not require heavy weight coding and do not affect performance itself significantly. These techniques also use readily available tools for collecting and parsing the results.

Related Books

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

Quick Resource Box

• JOHN ROBBINS' BLOG
• Mark Russinovich
• Process Monitor
• DebugView 

The rest of the post is a simple walkthrough of using the API and collecting the events in Procmon.

Step-by-Step Walkthrough

• Step 1 – Compile solution. John shares a source code. Download it here. It is Visual Studio 2008 project. It’s possible to compile it with Visual Studio 2010. I used VS 2010 RC. The result is 3 binaries:
  • ProcMonDebugOutputx64.dll – native code dll that reports events to Procmon on 64 bit machine for 64 bit processes.
  • ProcMonDebugOutputx86.dll - native code dll that reports events to Procmon on 32/64 bit machine for 32 bit processes.
  • Sysinternals.Debug.dll – managed code dll that calls either of the above depending on the process that runs it.
• Step 2 – Report events from your app.  When using it from managed code use System.Diagnostics.Trace.WriteLine(“your message to procmon”). I use it massively when inspecting performance issues. I usually collect the messages with another free xcopy tool from sysinternals – DebugView. Remember to put the three dll’s created in Step 1 into your bin folder.
• Step 3 – Configure trace listener in config file. John implemented tracelistener in his Sysinternals.Debug.dll. Following is the configuration needed to enable it collecting events from the application and passing them to Procmon:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true">
      <listeners>
        <add name="procmon" type="Sysinternals.Debug.ProcessMonitorTraceListener, Sysinternals.Debug"></add>
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

• Step 4 – Test the solution. Test the solution by running the Procmon and then your application. Make sure “Show Profiling Events” button is pressed on the toolbar. For test purposes I have implemented a code that issues web requests to microsoft.com and prints out the response. Note, the code is for demo only – it’s not optimized for performance and reliability. Here it is:

static void Main(string[] args)
{ 

    Trace.WriteLine("Entering MAIN");
    //http://msdn.microsoft.com/en-us/library/system.net.webrequest.aspx
    WebRequest request = WebRequest.Create(http://www.microsoft.com);
    HttpWebResponse response = (HttpWebResponse)request.GetResponse();
    Stream dataStream = response.GetResponseStream();
    StreamReader reader = new StreamReader(dataStream);
    string responseFromServer = reader.ReadToEnd();
    Console.WriteLine(responseFromServer);
    reader.Close();
    dataStream.Close();
    response.Close();
    Trace.WriteLine("Exiting MAIN");
}

Following is the output of the execution of this code as it shows in new and improved Procmon – you can see that both application and system events live in harmony and you can see the latency each one of them contributes:

Heaven… :)

Thank you, Mark and John.

Related Books

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