Does WCF use the ThreadPool to bring up new instances for a PerCall service?

Question

for a PerCall WCF service whose throttling has been set to be high (say, 200 max concurrent calls) would WCF bring up a new instance and invoke the request on a threadpool thread?

If it does, then does this have an impact on the total number of concurrent calls allowed?

I ask because I don't seem to ever hit the max number of concurrent calls I've set in the service throttling config but instead a fraction of that number - up to 50 on a 100 MaxConcurrentCalls setting and 160 on a 200 MaxConcurrentCalls setting.

Thanks,

Answer 1

It appears that WCF uses managed I/O threads from the CLR ThreadPool to service requests with the additional caveat that is uses its own thread scheduler.

From Wenlong Dong's Blog - Why Are WCF Responses Slow and SetMinThreads Does Not Work?

First of all, WCF uses managed I/O threads to handle requests. The CLR ThreadPool keeps a certain number of idle I/O threads from being destroyed. When more I/O threads are needed, they are created by the ThreadPool, which is kind of expensive.

From Wenlong Dong's Blog : WCF Request Throttling and Server Scalability

In .NET 3.0 and 3.5, there is a special behavior that you would observe for IIS-hosted WCF services. Whenever a request comes in, the system would use two threads to process the request: One thread is the CLR ThreadPool thread which is the worker thread that comes from ASP.NET. Another thread is an I/O thread that is managed by the WCF IOThreadScheduler (actually created by ThreadPool.UnsafeQueueNativeOverlapped).

There are a plethora of settings that factor into WCF throughput. Because WCF uses the managed ThreadPool, the ThreadPool's MinIOThreads and MaxIOThreads settings will affect the outcome. After all idle I/O threads (or worker threads if you were using those) are taken from the ThreadPool, the ThreadPool will delay for a period of time before spinning up a new thread to service a queued request. By increasing MinIOThreads, you can prevent this delay. If you are hitting the MaxIOThread limit, that would certainly cap the number of concurrent requests you would see; however, this doesn't appear to be the case in your 50/100 test because your next test managed to get 160 concurrent requests running. If I recall correctly, I believe the hosting environment you use (IIS, WAS, self) can dictate some of the ThreadPool settings. Also, if you read the blog post from the second link you will see how IIS worker threads get blocked when WCF is processing a request on its separate I/O thread. So in this case, worker thread settings and IIS settings would have an effect on WCF concurrency. How are you hosting this service?

Your title mentions a PerCall InstanceContextMode which will make the ConcurrencyMode irrelevant. However, with PerCall you will need to be aware of the MaxConcurrentInstances setting as well as the MaxConcurrentCalls. Depending on your binding, you may also need to be concerned with the MaxConcurrentSessions property. What binding are you using to host this service?

Regardless of all of the above, what is perplexing is the 160/200 test that followed your 50/100 test.