Backstory
We are using several Aspose components in our software, we use Aspose.Words and Aspose.BarCode. In our development environment we use a Windows AD (Active Directory) domain which everyone logs on to. Once logged on to the domain, we have no Internet connection, so we use virtual machines to log on to the domain. Our host PC’s remain their Internet connections.
Performance issue
Today I was analysing a performance issue in our applications. There was a substantial hickup near the initialization of the Aspose objects. After hours of profiling the application and testing on multiple PC´s, it turned out the performance drop only occured on PC´s which were logged on to the domain. On domain logins, it took 15 seconds to instantiate an Aspose component, on local computer logons, it only took 0,02 seconds.
At this point, I assumed that it could be one of two things. Either something with .Net framework security settings and being logged on to a domain, or a lag caused by the VPN we use to connect to the domain.
The first one was quickly dismissed, because .Net comes with caspol.exe to manipulate the security settings, and by running ´caspol.exe -security off’ I was able to test whether the security had anything to do with it. The execution time remained the same (15 seconds), so I don’t think this is the problem.
The second one I was able to dismiss by copying the test application to the Active Directory server, which is in the domain but doesn’t use a VPN, since it’s in the server network. Still the same execution time slash execution lag, so it can’t be the VPN.
So now what?
After scouring the whole Internet via Google and endless browsing through the Aspose forums I didn’t find an answer to my question, and although I got some very good help through the Aspose Live chat I still had a problem. Ready to give up, I decided to fire up Reflector to hopefully find something. Only to see that it took around 15 seconds to boot up. Hmmm. The one thing they shared and a test DLL which I wrote did not share was a digital signature.
For some reason I was at the same time installing a packet sniffer, and ran it while firing up Reflector. I saw some DNS request, which pointed to crl.thawte.com.
Turns out that…
It was an Internet option.
The .Net Common Language Runtime tries during the first time you run a digitally signed assembly to determine whether the signature is valid or not. It does so by contacting thawte or verisign, and the timeout if they cannot be reached (after which the assembly is allowed to continue without any warning) is, bingo, 15 seconds. It’s also cached so this happens only once, so it’s a bummer for those without an Internet connection ;-). You can disable this functionality in Internet Options.
The reason I post this message is that I spent a full day before I found out what was up, and just maybe by posting this, I’ll save somebody some time.
Thank you for the great components.