WCF 是否使用 ThreadPool 为 PerCall 服务创建新实例？

对于限制设置为高的 PerCall WCF 服务（例如，最大并发调用 200 个），WCF 是否会启动一个新实例并在线程池线程上调用请求？

如果是，那么这对允许的并发调用总数有影响吗？

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

Thanks,

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

From 董文龙的博客 - 为什么WCF响应慢并且SetMinThreads不起作用？ https://learn.microsoft.com/en-us/archive/blogs/wenlong/why-are-wcf-responses-slow-and-setminthreads-does-not-work

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

From 董文龙的博客：WCF 请求限制和服务器可扩展性 https://learn.microsoft.com/en-us/archive/blogs/wenlong/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 设置将影响结果。从 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 测试。