WCF vs in-process speed

  • Thread starter Thread starter GaryDean
  • Start date Start date
G

GaryDean

Thinking of doing our next project so that our logical tiers can be
physically tiered when desired for a given deployment and then not
physically tiered when that is not needed. The solution, we think, would be
using WCF and when we don't need to physically tier use named-pipes as the
transport.

However there will be a slowdown because of the WCF marshalling and
seralizing compared to in-process calls. My question is how much of a
slowdown will it be?
 
GaryDean said:
Thinking of doing our next project so that our logical tiers can be
physically tiered when desired for a given deployment and then not
physically tiered when that is not needed. The solution, we think, would be
using WCF and when we don't need to physically tier use named-pipes as the
transport.

However there will be a slowdown because of the WCF marshalling and
seralizing compared to in-process calls. My question is how much of a
slowdown will it be?
Click to expand...
Take a gander at http://msdn2.microsoft.com/en-us/library/bb310550.aspx,
which suggests that WCF over pipes will get you on the order of thousands of
requests per second. This clearly (and for obvious reasons) pales to
in-process calls (which can hit millions per second), so it all depends on
what you need to do, how much data is involved, how often you need to do it,
and what sort of scalability options you're looking at, because the only
reasonable answers to your question are "too much" and "acceptable".

If you're talking about a process that *might* be physically tiered, the
overhead you'd get from physical remoting would in turn put
WCF-through-pipes to shame, which would of course be compensated with the
increased processing power. Working out the performance details of that
scenario seems more interesting to me than worrying about the performance of
local WCF.
 
Given Jeroen's answer, it is probably best to not use named pipes
locally (obviously). You can still achieve your objective though if you
provide adapters for the logical tier that you would want to physically
separate.

ie: (pseudo code)

interface IServiceAdapter
{
string SayHello();
}

class LocalServiceAdapter : IServiceAdapter
{
string SayHello() { return ServiceBL.SayHello(); }
}

class RemoteServiceAdapter : IServiceAdapter
{
string SayHello() { ... WCF Call to where ServiceBL is... }
}

class ServiceBL
{
string SayHello() { return "HI!"; }
}

class ServiceAdapterFactory
{
IServiceAdapter GetServiceAdapter()
{
... either Local or Remote ServiceAdapter based on config ...
}
}

The client code would just need to call all logic through the adapter
instance.

I haven't done any WCF work yet, but have been doing Remoting for quite
some time with the above.
 
Back
Top