Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

April, 2010

  • Alik Levin's

    Sysinternals ProcMon New & Improved – Captures Both System & Application Events

    • 0 Comments
     Alik Levin    This post inspired by fantastic news I heard over at John Robbins blog of Wintellect. John collaborated with Mark Russinovich. Mark made it possible for Process Monitor [ProcMon] to collect events reported by an application and John wrapped a nice API that can be used either from native or managed code.

    Quick Resource Box

    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:

    image

    Heaven… :)

    Thank you, Mark and John.

    Related Books

  • Alik Levin's

    File Upload In A Web Test: The Case Of Submitting A Form With JavaScript

    • 0 Comments
     Alik Levin    This post documents steps we have taken to simulate file upload with Web Test when the form is submitted via JavaScript [vs. simple postback]. Credits go directly to Shai Raiten, MVP, brilliant young man, and the mind behind the workaround.

    Quick Resource Box

    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:

    image 

    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:

    clip_image001

    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:

    clip_image001[5]

    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

  • Alik Levin's

    Fiddler Extensibility: Flagging ASP.NET Performance Problems

    • 2 Comments
     Alik Levin    Although Fiddler PowerToy - Part 2: HTTP Performance is quite dated article about Fiddler, I constantly find very useful and practical gems in it. Flagging performance problems by coloring outstanding requests is one of them.

    Quick Resource Box

    In the article Eric Lawrence, the author and the creator of the Fiddler tool, shares simple technique of adding custom rules that color outstanding request – be it improper caching or large payload.

    Adding Custom Rules To Fiddler

    I am using Fiddler v. 2.2.8.6. To add customer rules follow these steps:

    • Click Rules in the menu.
    • Click Customize Rules… or Ctrl+R.
    • You should see CustomRules.js opened in Notepad.
    • Scroll down to the line with the following function:

    static function OnBeforeResponse(oSession: Session)

    • Add the following lines to the function (taken from the article):

    // Flag files over 25KB
       if (oSession.responseBodyBytes.length > 25000)
      {
          oSession["ui-color"] = "red";
          oSession["ui-bold"] = "true";
          oSession["ui-customcolumn"] = "Large file";
       }

    // Mark files which do not have caching information
    if (!oSession.oResponse.headers.Exists("Expires") &&
    !oSession.oResponse.headers.Exists("Cache-Control"))
    {
          oSession["ui-color"] = "purple";
          oSession["ui-bold"] = "true";
          oSession["ui-customcolumn"] = "Review Caching";
    }

    • Save the file by pressing Ctrl+S, and close the Notepad.

    Testing Fiddler Custom Rules

    To test the Fiddler custom rules just navigate to the site you want to inspect. Here is what I get after navigating the home page of my blog:

    image

    Highlighting potential performance problems helps quickly focus on it and start improving. Notice the request #3 colored in red – it exceeds 25 KB limit. Request #8 does not have caching header defined for it – colored in purple. Notice also the comments in Custom column. I could go further and and fine tune it, for example filter out 404, etc.

    Conclusion and Recommendations

    Recent announcement from Google that it incorporates performance into ranking algorithm makes the performance a serious  competitive advantage. I can easily imagine new breed Google performance consultants stealing a pie from SEO consultants. I guess it’d be a good move for any SEO consultant to get perf under their belt. Using Fiddler  makes it really easy.

    Related Books

      Related Posts

    Page 1 of 2 (6 items) 12