.NET Framework 3.0 and performance

I would like to welcome any new readers (which would be everyone, since this is my first post) to this attempt of mine to document my findings in the software development field. My big swedish fan base may be disappointed in the fact that I have decided to publish this thing in english, but I really would like to share information with all nationalities.

I've been getting my hands dirty with the new .NET Framework 3.0, and more specifically, the Windows Communication Foundation part. Up until a week ago, I had been using the June CTP, since this was the latest version with a set of functioning add-ons for Visual Studio 2005. On September 1st, Microsoft released the .NET Framework 3.0 RC1. The RC1 doesn't hold many new features compared to the July CTP, but instead focuses on increased performance and stability. I was curious to see what the differences were, if any.

Experiences and impressions
Let me first tell you that I am very impressed with how the WCF architecture is constructed. It is very versitile, designed to be the new communication architecture for many years to come, with its own customizable channel stack at heart. And yet, it is extremely simple to work with. Let me enumerate a few of the things I found very useful:

• Ability to host services in any executable, be it the IIS, a windows service or a console application
• Very flexible and extendable architecture
• Enabling use of other protocols than HTTP, such as raw TCP or Named Pipes
  
• Services configurable through web.config/app.config, so for instance changing the network protocol does not require a recompilation
• Support for using multiple endpoints and different protocols at the same time

If you need a crash course in WCF, this article does a pretty good job.

RC1 performance
I have experimented with performance and found that RC1 is definitely a bit faster than the older June CTP. This is most visible when making HTTP calls, since these include more overhead and thus take more time generally than, for instance, TCP. Where a call would take 250 ms with the June CTP, I was now down to around 200 ms with the RC1. Similarly, TCP calls were generally around 10-11 ms with the June CTP, while the RC1 pushed them down to the 7 ms neighbourhood. With named pipes, I got down to 5 ms. These tests were all run with empty method bodies - to get the pure response times, built in release mode and running as a windows service on a virtual machine. I'm sure you would get even better performance on a physical machine. Enabling basic security settings unfortunately impedes performance drastically.

Think about it... 7 ms for a web service call is not much. The traditional web service HTTP call would take 30 times longer. So what does this imply?

You could design your services so that they communicate with other services on the same LAN using TCP calls, while HTTP endpoints would be exposed for consuming applications, internal or external. Technically, the only thing that has changed when using TCP instead of HTTP is just that, the transport protocol. The payload is still the same, following the same WS-* and SOAP standards, so compatibility shouldn't be a big factor. You might still want to expose a HTTP endpoint simply because most implementations assume that web services are run through a web server, and thus HTTP. I see great potential to write more efficient service oriented code here.