Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

August, 2007

  • Alik Levin's

    Use Performance Counters Templates To Streamline Performance Analysis

    • 2 Comments

    I create perf counters sets up front. That way I could start collecting and measuring proper metrics right away each time I am assigned to do detailed performance analysis.

    Measuring .NET Application Performance lists important perf counters. What I really love about it is that the guide holds the list of performance counters to collect, explanation for each why collecting it, and the thresholds.

    Here are the steps I take creating performance counters templates:

    • Open perfmon MMC (start-> run -> perfmon -> Enter)
    • Expand "Performance Logs and Alerts" node
    • Right click on "Counter Logs" node and click "New Log Settings", provide some name for the new log and hit Enter.
    • Add counters to measure - right from Measuring .NET Application Performance.

    This is how it may look:

    imageNext would be saving the performance sets I created as depicted. It is done easy by right clicking each and saving it as html page. The resulting html page displays ActiveX with the performance counters in the set.

    To restore the performance counters-set to measure it  on another computer right click on "Counter Logs" and chose "New Log Settings From..." and point to your html file.

    One pitfall though. If the performance counters settings were created for specific computer then it will fail when recreating it on another. To fix it open html setting file in Notepad, remove \\MyComputer and save the file. For example:

    Before

    <PARAM NAME="Counter00005.Path" VALUE="\\MyComputer\System\Context Switches/sec"/>

    After

    <PARAM NAME="Counter00005.Path" VALUE="\System\Context Switches/sec"/>

    That means that performance counters are valid for current computer.

     

    Enjoy

  • Alik Levin's

    Client Certificates Authentication - Dirty Trick To Disable CRL Check. For Demos Only!

    • 1 Comments

    My lab domain has MS CA installed in it so I am able to issue certificates to the left and to the right. Recently I spent some time to understand why client certificates authentication does not work. More precisely the certificates dialog box was offering no client certificate to chose, as depicted below:

    image

    I first thought it is something on the client machine but after some investigation it turned out that it is IIS' part. IIS was unable to verify CRL. I was not in the mood of deploying CRL's so I decided to look into how to disable this feature. Here it is:

    http://forums.iis.net/t/1100044.aspx

       Set oWeb = GetObject("IIS://localhost/W3SVC")
       oWeb.CertCheckMode = 1
       oWeb.SetInfo
       Set oWeb = Nothing

     

    Open notepad paste the code above and save with vbs extension. Run it by double clicking it. Your IIS now do not give a damn about CRL.

    NOT THE BEST OPTION FOR PRODUCTION ENVIRONMENT.

    Good enough for demos.

    Enjoy.

  • Alik Levin's

    Web Services Over SSL - Is It Really That Slow Like They Say?

    • 2 Comments

    My answer is "no".

    I am working on solution where there is no Windows Active Directory Domain so we cannot utilize our beloved Kerberos and Windows Integrated Authentication saving big on configuration and management while taking advantage of increased security it offers.

    Other technique that we thought that could give us a lots of benefits in terms of strong authentication, transport level protection, and interoperability was using Client Certificates.

    Here is the scenario.

    ASP.NET web page calls on ASP.NET Web Service on separate machine. Think of scenario where Internet facing ASP.NET web site calls on Web Service deployed in internal zone:

    image

    The other scenario would be so called B2B scenario where intranet facing ASP.NET web site calls on Web Service over the Internet:

    image

     

    Another scenario would be calling Java Web Service.

    Not that friendly for Windows Integrated Authentication.

    The question we asked ourselves was - will it be fast enough? The following post by my colleague Eddie - Fast and Secured: Performance Impact of SSL gave us a lots of hope. But it discussed SSL between Web Browser and the Web Server. Web Browser (IE) has nice feature of caching SSL state so what depicted below happens less thus improving performance (think of OLEDB Connection pooling and you got the idea):

    image

    Well, our beloved Internet Explorer does a great job, what about .Net?

    After some research we happily discovered the following:

    http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.aspx

    clip_image001Note:

    The Framework caches SSL sessions as they are created and attempts to reuse a cached session for a new request, if possible. When attempting to reuse an SSL session, the Framework uses the first element of ClientCertificates (if there is one), or tries to reuse an anonymous sessions if ClientCertificates is empty.

    That was encouraging and I decided I need to see it my eyes, so I set sample code and deployed to my lab domain. I also have used diagnostics technique described in Use Sysinternals DebugView To Diagnose The Application. When I fired up DebugView this is what I saw:

    image

     

    Each pair of records reflects on single Web page access telling me how many milliseconds was spent on each action to complete during the page processing.

    Notice first two records - one for Web Service proxy creating and adding certificate to it:

                //START STOPWATCH

                Stopwatch stopwatch = new Stopwatch();

                stopwatch.Start();

                //GET HOLD ON CERT

                X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);

                store.Open(OpenFlags.ReadOnly);

                X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindBySubjectName, "w3w1", true);

                X509Certificate2 cert = certs[0];

                //CREATE WEB SERVICE PROXY

                Service1 proxy = new Service1();

                proxy.ClientCertificates.Add(cert);

                Debug.WriteLine("Web Service Proxy Created: " + stopwatch.ElapsedMilliseconds.ToString());

     

    and the second one is actual Web Service call:

                // CALL ON WEB SERVICE

                string result = proxy.HelloWorld(cert.Subject);

                Debug.WriteLine("Web Service Call Completed: " + stopwatch.ElapsedMilliseconds.ToString());

     

    Notice that all subsequent calls are pretty fast. It should prove that SSL session caching is in place also with .Net as promised. Cool.

     

    Conclusion

    While these numbers have been taken on lab environment for super simple scenario it can serve as talking point when considering applying SSL to protect your sensitive data to its way to downstream servers. Also client certificate authentication should be considered as a strongest authentication available today when Kerberos is not available.

Page 2 of 2 (6 items) 12