Suppose you expose a WCF Service from one project and consume it in another project using 'Add Service Reference开发者_StackOverflow中文版' (in this case a Framework 3.5 WPF Application).
Will ClientBase perform any kind of connection pooling of the underlying channel when you re-instantiate a ClientBase derived proxy or will you incur the full overhead of establishing the connection with the service every time? I am especially concerned about this since we are using security mode="Message" with wsHttpBinding.
Please take a look at this article which describes best practices on how to cache your client proxies. If you're creating your proxy directly (MyProxy p = new MyProxy(...)
), then it seems that you really can't cache the underlying ChannelFactory, which is the expensive part. But if you use ChannelFactory
to create your proxy, the ChannelFactory
is cached by the proxy at the AppDomain level, and it's based on the parameters you pass to the proxy (kind of like connection pooling which is based on the connection string).
The article goes through a number of details on what's going on under the covers, but the main point is that you get a performance bump if you use ChannelFactory
to create your proxy instead of instantiating it directly.
Hope this helps!!
This article explains that yes, there is TCP connection pooling for WCF. What it doesn't explain though is in which cases it will take effect. As far as I can tell, as long as you construct your proxy object by providing it a named endpoint (IE not using a custom Binding
object), connection pooling will work. I tested this by throwing load at my web app and checking open TCP connections with netstat
.
But the bottom line is you do not need to cache your proxy objects in order to re-use the TCP connections.
精彩评论