WCF是否使用ThreadPool为PerCall服务提供新实例？

Question

对于一个被设置为高限制(比如，200个最大并发调用数)的WCF服务，PerCall会带来一个新的实例并调用线程池线程上的请求吗？

如果是这样，那么这是否会对允许的并发调用总数产生影响？

我之所以问这个问题，是因为我似乎从来没有达到过我在服务限制配置中设置的最大并发调用数，而是这个数字的一小部分--在100 MaxConcurrentCalls设置下达到50，在200 MaxConcurrentCalls设置下达到160。

谢谢,

Answer 1

似乎WCF使用来自CLR ThreadPool的托管I/O线程来服务请求，但需要注意的是，它使用了自己的线程调度程序。

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

首先，WCF使用托管I/O线程来处理请求。CLR ThreadPool可防止一定数量的空闲I/O线程被销毁。当需要更多的I/O线程时，它们是由ThreadPool创建的，这是一种昂贵的开销。

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

在IIS3.0和3.5中，对于.NET托管的

服务，您会观察到一个特殊的行为。每当有请求进入时，系统都会使用两个线程来处理请求:一个线程是CLR线程，它是来自ASP.NET的工作线程。另一个线程是由 IOThreadScheduler管理的I/O线程(实际上是由ThreadPool创建的

有太多的设置会影响WCF吞吐量。由于WCF使用托管ThreadPool，因此线程池的MinIOThreads和MaxIOThreads设置将影响结果。从ThreadPool中取出所有空闲I/O线程(或工作线程，如果您正在使用这些线程)之后，ThreadPool将延迟一段时间，然后才会启动一个新线程来为排队的请求提供服务。通过增加MinIOThreads，您可以防止此延迟。如果您达到了MaxIOThread限制，那么您将看到的并发请求数量肯定会受到限制；然而，在50/100测试中情况似乎并非如此，因为您的下一个测试设法让160个并发请求运行。如果我没记错的话，我相信你使用的主机环境(IIS，WAS，self)可以决定一些ThreadPool设置。此外，如果您从第二个链接阅读博客文章，您将看到当WCF在其单独的I/O线程上处理请求时，IIS工作线程是如何被阻塞的。因此，在这种情况下，辅助线程设置和IIS设置将对WCF并发性产生影响。您是如何托管此服务的？

您的标题提到了一个PerCall InstanceContextMode，它将使ConcurrencyMode变得无关紧要。但是，使用PerCall时，您需要了解MaxConcurrentInstances设置以及MaxConcurrentCalls。根据您的绑定，您可能还需要关注MaxConcurrentSessions属性。您使用什么绑定来托管此服务？

不管以上所有情况，令人困惑的是在您的50/100测试之后的160/200测试。