Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices

[WCF] Miglioramenti nelle performance in .NET 3.5

BlogServiceHost.Create() — Mon, 29 Oct 2007 00:42:53 GMT

Interessantissimo postdi Wenlong Dong, membro del team WCF Performance, che descrive i miglioramenti

.Net 3.0 SP1 e WCF performance improvement

Stefano Paluello's Blog — Mon, 29 Oct 2007 12:56:59 GMT

.Net 3.0 SP1 e WCF performance improvement

Beyond the Obvious: New Features and Fixes for WCF in .NET 3.5

Christian Weyer: Smells like service spirit — Mon, 29 Oct 2007 17:49:13 GMT

With .NET 3.5 and Visual Studio 2008 being quite close to RTM these days, I thought it would be time...

re: Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices

omario — Tue, 30 Oct 2007 13:28:41 GMT

"You need to handle exceptions and retries for the pool."

In what conditions proxy should not be returned to the pool? Is it enough for proxy to be in Faulted state?

Better Proxy Clients

Noticias externas — Tue, 30 Oct 2007 16:44:34 GMT

I was in a meeting last week with a few WCF users at Microsoft when they asked about performance issues

WCF performance

Miguel Campos Blog — Tue, 30 Oct 2007 21:36:55 GMT

Found this article on improving WCF proxy performance and considerations, http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.asp

re: Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices

RobertTostevin — Wed, 07 Nov 2007 21:06:27 GMT

In .NET3 we are using a WCF service to talk to a WF. The WCF service is being called by an ASP page request. In order to optimize performance we are using a singleton proxy class which is shared by all page requests on the same server. The GUID is obviously part of the params passed to the WCF service which then routes the Event to the right WF. In .NET 3.5 if we were to switch to using the new WorkflowServiceHost & the new Receive Activity the GUID is part of the contextchannel & therefore part of the message being sent by the proxy class. My understanding is that reuse of the proxy via our singleton will fail as each Page would need to block the other pages requests whilst it makes its call (as it would need to change the GUID in the context)ie we lose our scalability.

... Is that Correct ?

If so how can this be made more scalable so that each page request doesn't have to go through the expense of creating a brand new proxy each time ?

Thanks

Rob.

re: Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices

wdong — Thu, 08 Nov 2007 05:05:01 GMT

Hi Rob, that's a good question. I have just posted another blog entry for this: http://blogs.msdn.com/wenlong/archive/2007/11/08/how-to-use-a-singleton-wcf-proxy-to-call-different-workflow-service-instances-in-net-3-5.aspx

Please let me know if this answers your question above. Thanks!

A Sample for WCF Client Proxy Pooling

Wenlong Dong's Blog — Wed, 14 Nov 2007 09:45:42 GMT

Introduction Ideally we should not need to pool WCF client proxies as I mentioned in my previous blog

A Sample for WCF Client Proxy Pooling

Noticias externas — Wed, 14 Nov 2007 10:18:54 GMT

Introduction Ideally we should not need to pool WCF client proxies as I mentioned in my previous blog

re: Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices

MCGP Peters — Fri, 28 Dec 2007 18:17:33 GMT

"If you have such a scenario, please do let me know."

A scenario would be an intermediate, where a WCF service is used to forward calls to other service end-points. You would like to keep a pool of channels to the previous called end-points...

WCF without Svcutil tool

Diego Baroffio's Blog — Thu, 10 Apr 2008 16:25:09 GMT

Introduction This week it was asked to me to find some elegant and practical way to use WCF. After some

Avoid using “using()”

ÎÜñ|‹ø\/\/ñ [ÐëÞrëçã†ëð]'s Blog — Sun, 21 Sep 2008 14:14:22 GMT

The using statement in C#, seems to be quite useful especially to a developer as theoretically, you not

Don't access public properties?

marc_opus — Fri, 17 Oct 2008 14:55:51 GMT

Hi Wenlong,

what exaclty do you mean with

"Don’t access the public properties ChannelFactory, Endpoint, and ClientCredentials of the proxy"

in the listing what to be aware to not implicitly disable the caching? Is this valid for set only or also for get? I'm asking because we have an application that writes some addressing stuff to the trace, and is accessing the above mentioned properties. If this prevents the caching, we could get over the missing trace as tradeoff against better performance.

Thanks,

Marc

Proxy Caching Changes

Nicholas Allen's Indigo Blog — Fri, 17 Oct 2008 16:13:36 GMT

I don't think I ever wrote about the changes made to WCF generated typed proxies in Orcas, although Wenlong

WCSF Application Architecture 7: Remote Logic with WCF Services

Simon Ince's Blog — Thu, 20 Nov 2008 20:21:27 GMT

This article is part of a series; · WCSF Application Architecture 1: Introduction · WCSF Application

Caching Bug

tmanthey — Sun, 28 Jun 2009 16:18:47 GMT

Unfortunately the caching of the ChannelFactory has become a reference example why caching is dangerous. Still 3.5 SP1 contains a subtle yet nasty bug. It surfaces once you try to call the ClientBase<T>.Open() method. This can be preferable if you try to reduce the (tremendous) time a first call to a service consumes. The call is forwarded to the ChannelFactory which in case it was cached can be already in "Opened" state, while the ClientBase object is still in "Created" state. I see it once in a while, but have not yet been able to reproduce it in a reliable manner.

In this case you see the exception:

The communication object, System.ServiceModel.ChannelFactory`1[IMyService], cannot be modified while it is in the Opened state.

To work around check the state of the ClientBase<T>.ChannelFactory to be "Created" property before calling ClientBase<T>.Open()

http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=456192

re: Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices

UrmilShah — Sun, 22 Nov 2009 22:02:22 GMT

I am not sure why caching proxy / channel will give better output. Shouldn't it create bottleneck in high traffic website?

Webservices / WCF over IIS are kind of websites only.

For example If I am accesing 10 request using one browser vs requesting 10 request in 10 different browser (multithreaded way).

How Cahing of proxy / channel will react for Async calls? Appreciate any help here.