对于其限制设置为高（例如，200个最大并发调用）的PerCall WCF服务，WCF会调出一个新实例并在线程池线程上调用该请求吗？
如果是，那么这会对允许的并发呼叫总数产生影响吗？
我问，因为我似乎没有达到我在服务限制配置中设置的最大并发呼叫数，而是达到了该数字的一小部分 - 在100 MaxConcurrentCalls设置中最多50个，在200上200 MaxConcurrentCalls设置。
谢谢，
答案 0 :(得分：16)
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
在.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测试。