Is it really worth pooling WCF proxy clients, or is it better to instanciate a new proxy on every call to a given method?
By the way, does anyone have a pooling pattern for this kind of proxies which he/she is willing to share?
Is it really worth pooling WCF proxy clients, or is it better to instanciate a new proxy on every call to a given method?
By the way, does anyone have a pooling pattern for this kind of proxies which he/she is willing to share?
It is worth to cache ChannelFactory
because its construction is costly. Proxies generated by Add Service Reference (or svcutil.exe
directly) do this in some scenarios (generally you must not build binding in code if you want to have this caching). If you build ChannelFactory
manually (you don't use generated proxies) it is up to you to store it somewhere instead of initializing it every time you need it.
Pooling proxies probably doesn't make much sense. For stateless services the proxy creation should be fast (if you have cached factory). For statefull services you don't want sharing proxy among multiple "clients". There is also pooling on connection level itself. HTTP bindings use something called persistent connections by default. These connections can be reused by multiple proxies. Net.tcp and net.pipe bindings use connection pooling internally. It means that lifetime of the proxy doesn't have to be the same as lifetime of the connection.