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.