Problems with WCF Scaling

Every once in a while, people ask me about problems they have when trying to use a single WCF service with multiple concurrent calls.

The first think I tell them is to check their WCF throttling settings. The throttling behavior in WCF controls how many instances and session WCF can create and manage at once.

These settings also depend on the binding you use. For example if you have a single proxy on the client side that sends many async calls at once, and you use basicHttpBinding, WCF will by default create many instances on the service side, this is because basicHttpBinding does not support sessions. If you change the binding to wsHttpBinding which supports sessions, you will end up using a single instance (this of course depends on the instance context mode of your service).

In WCF 3.5 the throttling settings were quite low, but in .NET 4 they were increased and now they depend on the number of cores your machine has.

Of course this is the obvious reason, but after solving this issue, some people find another problem with concurrent calls, usually when making a lot of concurrent calls that span many service instances. The problem with creating a lot of service instances at once, even after increasing the throttling values, relies in the fact the WCF uses the ThreadPool to create to queue the work, and the ThreadPool controls how many threads are available for work and how to create new threads (this is the MinIOThreads setting). The ThreadPool has a minimum of threads which is set according to the machine’s CPU, and can be changed if needed (note the bug that exists in the CLR in .NET 3.5).

Read more: Ido Flatow

Posted via email from Jasper-net