WCF is slow when reliable session is ON and with burst async request

Question

For experiments, I created a simple \"Hello World\" WCF service and client using .NET 4.5 on VS2012. The server is hosted on a console application and use net.tcp binding. I

Answer 1

Look at this...

"Setting MaxTransferWindowSize

Reliable sessions in Windows Communication Foundation (WCF) use a transfer window to hold messages on the client and service. The configurable property MaxTransferWindowSize indicates how many messages the transfer window can hold.

On the sender, this indicates how many messages the transfer window can hold while waiting for acknowledgements; on the receiver it indicates how many messages to buffer for the service..."

Source "MSDN: Best Practices for Reliable Sessions": http://msdn.microsoft.com/en-us/library/ms733795.aspx

Answer 2

You are sending messages Async, but you have ordered="true" on the ReliableSessionBindingElement. This doesn't make sense. Set ordered to false, since it makes more sense for your scenario. ReliableMessaging will cause a performance hit because it adds to every response message a SequenceAcknowledgement. It also adds overhead of CreateSequence/CreateSequenceResponse and CloseSequence/CloseSequenceResponse, then TerminateSequence/TerminateSequenceResponse message exchanges at the beginning and end of your session.

Answer 3

Found a partial workaround for the problem from the below links:

• http://blogs.msdn.com/b/endpoint/archive/2011/05/04/wcf-scales-up-slowly-with-bursts-of-work.aspx
• http://support.microsoft.com/kb/2538826

With the workaround (using the WorkerThreadPoolBehavior), the measured throughputs are as follows:

1. Async + NetTcpBinding/Reliable throughput -> 474 call/s (2.1 ms/call) ... improved but not satisfactorily
2. Async + WsHttp/Reliable throughput -> 7856 call/s (0.13 ms/call) ... no change
3. Sync + NetTcpBinding/Reliable throughtput -> 2110 call/s 0.47 ms/call) ... degraded

Note that the case 1 above is improved significantly from 70 ms/call. However, it still lags from case 2. And for case 3, introducing WorkerThreadPool behavior cause performance degradation from 0.25 ms/call to 0.47 ms/call.