tags:

views:

454

answers:

2

We are running a service that requires fast communication with another process. Currently we are using WCF NetNamedPipeBinding in buffered mode to invoke methods in the service, which seems to offer the least overhead of the available WCF bindings. Is there a faster way to do this using managed code?

Edit: Bunching requests as suggested below is an option already considered. Really, we're wondering whether or not there is an alternative API for inter-process comms that outperforms WCF using named pipes.

+1  A: 

Well, are you volume-bound (i.e. big messages) or round-trip bound (lots of small messages)?

For big messages, consider compression (if network IO is the overhead) or more efficient serialization such as protobuf-net.

For chatty APIs, consider bunching messages to take fewer round trips.

Marc Gravell
It's going to be more of a chatty API. One of its purpopses is to service autocomplete requests from a web page, so bunching won't be an option in this case, but in other cases this should reduce traffic between two and tenfold.
spender
+6  A: 

If you're using WCF then named pipes are the fastest way to communicate on the local system.

If you are throwing a whole lot of data around then you could look into streaming your APIs (simply added a System.IO.Stream as the parameter instead of passing an array or string etc.)

Also for performance, your hosting model is very important as well, in regards to your instance mode of the service. Juval Lowy's book on WCF is actually really good when you get past the code examples into the meat of his book.

EDIT: In response to your comment, have a look at the "ServiceBehaviour" attribute you can apply to service definition. (not your IServiceInterface description, but your concrete implementation of your class).

You can define your code to instance by PerCall, PerSession or Singleton. Default is singleton PerSession(thanks @RichardOD) with concurrency mode set to single and the instanceContextMode set to true, which allow you to host WCF on a windows form and prevents you from shooting yourself in the foot if you don't understand the instancing.

Basically if you leave it to the default, you end up with a single threaded, sequentially processed WCF host.

MSDN has some reasonable information on what each type does.

Spence
Spence, can you flesh out what you mean by "instance mode of the service". Currently it runs as a self hosted ServiceHost, which in turn is hosted in a standard Windows service
spender
@Spence. The default isn't Singleton, it is PerCall or PerSession depending on if the channel supports sessions.
RichardOD
1 point to @RichardOD. My apologies, confused that with the default of ConcurrencyMode single, which is the point I was trying to get to, default settings are zero concurrency which will affect scalability.
Spence
@Spence- no worries- still a good answer.
RichardOD