Juicing up your WCF services

This weekend has been so relaxed that I'm almost ashamed of it. However, I think I needed some quality do-nothing-at-all time, because I did start to feel tiny stress symptoms at the end of last week. Positive stress resulting in negative effects, I suppose. Feel back on track now. The swedish election is coming up, and I must say I find the debate shows on TV quite amusing; more so than earlier years.

However relaxed my weekend has been, the occasional debates and sushi eating aside, I did get quite a bit of time to play around with WCF. I couldn't resist that opportunity, could I?

Optimizing service events
I started delving into the wonderful world of duplex services, and thus, service callbacks. There is a lot to be explored here, and I have merely tapped into the very surface. Duplex services in WCF can be implemented using non-duplex protocols, such as HTTP. WCF does this by adding extra information to the SOAP header, for example by using the WS-Reliable Messaging specification and operating the service as a Composite Duplex (which essentially means combining two separate channels into one). There is a big drawback to using HTTP, though: services must use the wsDualHttpBinding binding, which is very slow. The wsDualHttpBinding binding is the only one of the HTTP bindings that support duplex services. So what can be done?

The answer is to use the netTcpBinding binding. TCP is by design a duplex protocol and is, as I explored in my last blog entry, very fast. With a TCP-based service, the callback performance does indeed improve drastically.

Just for fun, I decided to declare a customBinding binding and see if I could make the callbacks work that way as well. I started out with a custom binding that implemented the following channel stack, in order, top down:

• reliableSession
• textMessageEncoding
• tcpTransport

This worked like a charm - I still got my callback messages. I removed the reliableSession channel, and it still worked. I also noted a side effect, something that had been bothering me before. Service startup times were drastically shorter than that of any other pre-packaged binding I had tested, it even surpassed the netTcpBinding.

Optimizing service startup
As it turns out, when a service that implements the netTcpBinding starts up, it performs 44 DLL loads. The service implementing the customBinding performs 25 DLL loads. The interesting differences being one or more loads of:

• System.DirectoryServices.ni.dll
• ntdsapi.dll
  
• DNSAPI.dll
• Secur32.dll

This hints that it might be the security features of the netTcpBinding binding that takes up the extra load time, but I am yet to confirm this. Load times were over 1 second for the netTcpBinding service; the customBinding service was roughly 10 times faster, so quite a big difference.

I can't quite grasp these scenarios yet, but I think I'm fairly close to figuring out the cause and will get back to that in a later post. Cheers!