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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With