Does WCF optimize the client's connection under the hood?

Question

We are currently working on an application that will use a WCF service. The host (the client) is using the excellent WCF Service Proxy Helper from Erwyn van der Meer.

What I would like to know... is if I open this object multiple times... will it lead to multiple (expensive) connections or will WCF manage it and pool the connections.

The reason why I want to know this is because we will be calling methods of the service at different point in time within the same web request and we currently have wrapped the instanciation of the Service proxy class within the call.

Eg.:

MyService.MyMethod1() // wraps the connection usage as well as the call to the service

Any suggestions about how I would go to minimize the amount of connection while keeping the code conform with SRP would be excellent.

So? Any idea?

Answer 1

You should try to minimize the number of proxy objects you create. Proxies in WCF are quite expensive to set up, so creating one and calling functions on it multiple times is definitely more efficient than creating a new one for each method invocation.

The relationship between proxy objects and connections depends on the transport used. For http transports, an HTTP connection is initiated for each function invocation. For the net.tcp transport, the connection is established at Open() time and kept until a Close(). Certain binding settings (eg those supporting WS-SecureConversation) will incur extra "housekeeping" connections and message exchanges.

AKAIK, none of the out-of-the-box bindings perform connection pooling.

Answer 2

You might check this article for information about best practices using proxies.

Answer 3

It doesn't do pooling like SqlConnection, if that is what you mean.

[caveat: I use "connection" here loosely to mean a logical connection, not necessarily a physical connection]

Between using a connection on-demand, and keeping one around, there are advantages and disadvantages to both approaches. There is some overhead in initializing a connection, so if you are doing 5 things you should try to do them on the same proxy - but I wouldn't keep a long term proxy around just for the sake of it.

In particular, in terms of life-cycle management, once a proxy has faulted, it stays faulted - so you need to be able to recover from the occasional failure (which should be expected). Equally, in some configurations (some combinations of session/instancing), a connection has a definite footprint on the server - so to improve scalability you should keep connections short-lived. Of course, for true scalability you'd usually want to disable those options anyway!

The cost of creating a connection also depends on things like the security mode. IIRC, it will be more expensive to open a two-way validated connection using message security than it will to set up a TransportWithMessageCredential connection - so "YMMV" is very much the case here.

Personally, I find that the biggest common issue with proxy performance isn't anything to do with the time to set up a conncetion - it is the chattiness of the API. i.e.

Scenario A:

• open a connection
• perform 1 operation with a large payload (i.e. a message that means "do these 19 things")
• close the proxy

Scenario B:

• open a connecton
• perform 19 operations with small payloads
• close the connection

Then scenario A will usually be significantly faster due to latency etc. And IMO don't even think about distributed transactions over WCF ;-p