WCF是否使用ThreadPool为PerCall服务启动新实例？

Question

对于PerCall WCF服务，其调节已被设置为高（比方说200个并发调用），WCF会调出一个新实例并在线程池线程上调用请求？

如果是这样，那么这是否会影响允许的并发呼叫总数？

我问，因为我似乎并没有达到我在服务调节配置中设置的最大并发呼叫数量，而是这个数字的一​​小部分 - 在MaxConcurrentCalls设置为100，最多为50， 200 MaxConcurrentCalls设置。

感谢，

Answer 1

看来，WCF使用管理I/O线程从CLR线程池与另外需要注意的是使用它自己的线程调度的服务请求。

从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

在.NET 3.0和3.5，有一个特殊的行为，你会观察到了IIS托管WCF服务。无论何时请求进入，系统都会使用两个线程来处理请求：一个线程是CLR ThreadPool线程，它是来自ASP.NET的工作线程。 另一个线程是由WCF IOThreadScheduler管理的I/O线程（实际上由ThreadPool.UnsafeQueueNativeOverlapped创建）。

WCF吞吐量存在过多的设置因素。因为WCF使用托管的ThreadPool，所以ThreadPool的MinIOThreads和MaxIOThreads设置将影响结果。在所有闲置的I/O线程（或者使用这些线程的工作线程）从ThreadPool中取出之后，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测试。