views:

431

answers:

2

I am considering using a Shared (read static) WCF proxy client for a high throughput application. I believe there is a performance gain in doing this, but I have not benchmarked this as yet.

Are there some serious pitfalls to this idea?

From my research I can see that there is the issue of handling the fault state, it is not clear what the flow on affect of this state would be to other pending requests.

Does anyone have any experience recovering a WCF proxy from it's faulted state?

thanks in advance!

+1  A: 

Once the channel is in a faulted state it will stay that way. So yes, I think a static client would be problematic. I started off that way as well but ended up creating and opening a new channel for each call instead. There doesn't seem to be much of a performance trade-off.

For reference I'm doing about 30-60 requests of about 5K-30K per request per second on a quad core machine from another quad core machine. WCF has been holding up quite well so far.

fung
Did you try using the "client.InnerChannel.AllowOutputBatching = true;" ? I was thinking that this might be where the performance increase might lie
Harry
No, mine is quite an 'out of the box' config. The only things I changed were to increased the MaxItemsInObjectGraph and MaxRecievedMessageSize. Have not tried AllowOutputBatching. Would be interesting to see how well that works.
fung
A: 

I just discovered that calling Close() on the proxy will block when calls that are One Way operations executing [OperationContract(IsOneWay = true)]. This would change the flow as well.

Mark Lindell