Site Sections
Posts
11
Comments
6
Trackbacks
0
December 2008 Entries
Finding a performance issue with dynaTrace
Recently, I was asked to look into a performance issue we are having with a particular windows service when it is being communicated with a MMC snap-in we have developed.  Essentially the snap-in communicates with the service using WCF to get the data that populates a particular form.  When the form was loaded it could take between 10-30 seconds depending upon the data storage mechanisms on the backend.

Normally, figuring out what is going on with a Windows service can be a huge pain in the ass.  Everything is being tossed out on a seperate thread and you have to figure out what causes it to do what and what else is going on.

Fortunately, I have dynaTrace on my side!

So first thing I need to do is select my applications for instrumentation using the .Net Configuration Tool:



This basically lists every piece of managed code ever JIT'ed on my box.  What was interesting to me is that I do not think the Microsoft Management Console (mmc.exe) is managed code.  But, because it loads up my managed code it shows up in the list.  Because of this I could see what is happening on the console side.

I also chose to instrument the Windows Service as well.  The next thing you need to is determine the specific set of methods that are interesting in this scenario.  Doing this is no small trick and deserves a post onto itself so in the end I had this being reported in dynaTrace.



The big contributed here was the code in the namespace that took 39 seconds to execute, but that is not what I am going to focus on for this article.  While the developers were chunking on the code causing those issues I also noticed the GetDefaultCertificate code was taking 3 seconds or so.

The code is basically something like this:

            internal static X509Certificate2 GetDefaultCertificate()

            {

                  string certString = GetCertificateSetting();

 

                  if (string.IsNullOrEmpty(certString))

                  {

                        return null;

                  }

                  byte[] bytes = Convert.FromBase64String(certString);

                  X509Certificate2 cert = new X509Certificate2(bytes, "");

                  return cert;

            }

 

My code Nazi alarm goes off immediately because this code should definitely be a property (if your method is named Getwhatever that is usually your first clue). 

Leaving that be though, the thing I now know, because of dynaTrace, is that this psuedo-property is accessed 56 times, but does it really need to new'ed up each time?

Turns out that it does not.  That the certString never changes through the course of an execution (it is held in an App.Config which cannot change).  So this values should be set once and just referred to again and again like so:

        internal static X509Certificate2 GetDefaultCertificate

        {

            get

            {

                if (m_certification == null)

                {

                    string certString = GetCertificateSetting();

 

                    if (string.IsNullOrEmpty(certString))

                    {

                        return null;

                    }

 

                    byte[] bytes = Convert.FromBase64String(certString);

 

                    m_certification = new X509Certificate2(bytes, "");

 

                }

                return m_certification;

            }

 

        }


A very minor code change.  But one that would have been very difficult to see as necessary without dynaTrace pointing it out to me.
posted @ Monday, December 29, 2008 2:30 PM | Feedback (0)
Diagnostic tracing your application with dynaTrace

My company recently purchased a software called dynaTrace to be used for performance diagnosis.  It primarily started as a Java tool but they do support .Net as well.  Since my company is entirely .Net based I will explain the product from that point of view.

The application works by using MSIL injection to put essentially a header and footer into each method you have instrumented in an application.  If you do not know what MSIL Injection is here is a great overview on the PostSharp website, and here is a more detailed but not as accessible explanation of how to do it.

So as your applicaiton is running each instrumented method reports back to a diagnostic server which collects all the method calls and then strings them together.  There is a client application that connects up to the server and lets you see what is going on in a particular execution.  Each seperate transaction flow in your application, what dynaTrace calls a purepath, is knitted together so you can follow it all the way through.

The product can follow across web service, MSMQ, and remoting calls so that everything is seen together as one transaction.  The current version cannot do WCF but their next release (hopefully 1st quarter 2009) will.

So, let's say you had an instrumented ASP.Net website that when some user makes a request, it calls a web service which is also instrumented, which then contacts the database.  With dynaTrace we would see that as one request, it would be relatively transparent when the code executed across to the web service.  The calls the web service makes to the database are seen because ADO.Net is instrumented, but the database server itself is not directly instrumented.

So now I can see the total time of the web request , all the pieces of it, and what database calls are made.  With that information you can figure out what the big contributers are very easily. 

posted @ Wednesday, December 24, 2008 9:48 AM | Feedback (0)
SafeCode's Fundamental Practices for Secure Software Development

Several blogs I follow have mentioned that SafeCode has released there Fundamental Practices for Secure Software Development guide.  I had thought that this was released a while ago actually and the document is dated October 8th.  Oh well, it is a good reference regardless.

The mission of SafeCode.org is "SAFECode is dedicated to increasing trust in information and communications technology products and services through the advancement of proven software assurance methods."  They have a number of different organizations contributing to this effort, like Microsoft, EMC, Symantic and others.

I got to it by reading this article Secure Software Development Practices 'not rocket science'. 

posted @ Tuesday, December 09, 2008 9:23 AM | Feedback (0)
Microsoft's SDL Optimization Model

Microsoft's SDL Optimization model is for moving your organization along in their Security Development Lifecycle.  The SDL is really born out of a lot of lesson's learned and pain realized by Microsoft over the years.  The idea is to build into your development process a more security centric focus throughout the lifecycle.

The Optimization Model follows this diagram:

Microsofts Security Development Lifecycle Optimization Model

The idea here is to first determine where your organization is at, figure out where you want to be, and determine how to get there.  You start with an introduction document and move from there to a self-assessment.  Depending up on the assessment you will move on to an implementer's guide.

What I find helpful about this is it is difficult to figure out how to move an organization towards more secure development.  It is very helpful to have a demonstrable process that worked for somebody.  The fact that it came from Microsoft's own experiences and they are very enthusiastic about their success with it helps a lot.

It also hurts a little because they have already lined up a number of vendors, their SDL Pro Network, to evangelize the process (i.e. sell services and training).  Don't get me wrong I am all for making a buck but sometimes it can get a little tedious how much they are promoting it within their documentation.

I believe at some point it will be almost a requirement for software vendors (of whatever stripe) to have a demonstrable secure development process (for example the PA-DSS).  Too much money is being lost, too much information is at risk, and something definitely has to be done.  I am not positive that Microsoft's SDL will emerge as the solution for this but at this point it is better than nothing.

posted @ Monday, December 08, 2008 12:49 PM | Feedback (0)
Archives
Post Categories
News
Twitter