对于PerCall WCF服务的限制已被设置为高（比方说，200最大并发呼叫）将WCF带来了一个新的实例并调用一个线程池线程的要求？

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?

我问，因为我似乎没有以往任何时候都打到最大数，我在服务限制配置设置并发呼叫，而是这个数字的一​​小部分 - 高达50在100 MaxConcurrentCalls制定和160 200 MaxConcurrentCalls设置。

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.

谢谢

推荐答案

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

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.

从Wenlong东的博客 - ？为什么是WCF响应很慢和SetMinThreads不起作用

首先， WCF使用管理的I / O线程来处理请求。在CLR线程池保持一定数量的空闲I / O线程被破坏。当需要更多的I / O线程，它们由线程池，这是一种昂贵的创建。

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.

从Wenlong董的博客：WCF请求限制和服务器可伸缩性

在.NET 3.0和3.5，有一个特殊的行为，你会观察到的IIS托管WCF服务。每当一个请求时，该系统将使用两个线程来处理请求：一个线程是CLR线程池线程这是来自ASP.NET辅助线程。 另一个线程是由WCF IOThreadScheduler（由ThreadPool.UnsafeQueueNativeOverlapped实际创建）

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).

有过多的设置，析因入WCF吞吐量。因为WCF使用管理线程池，线程池的MinIOThreads和MaxIOThreads设置会影响结果。毕竟空闲I / O线程（或者，如果你正在使用这些工作线程）从线程池拍摄时，线程池将延迟一段时间旋转了一个新的线程来服务排队请求之前。通过MinIOThreads增加，你可以prevent这种延迟。如果你打的MaxIOThread的限制，这将肯定上限，你会看到的并发请求数;然而，这似乎并没有这样的情况在50/100测试，因为你的下一个测试设法运行160并发请求。如果我没有记错，我相信你使用的托管环境（IIS，WAS，个体经营）可以决定某些线程池的设置。此外，如果从第二个链接阅读博客文章，你会看到IIS工作线程被阻塞时，WCF在处理其独立的I / O线程的请求。所以在这种情况下，工作线程设置和IIS设置会对WCF并发的效果。你是如何主持此服务？

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?

您的标题提到了PerCall InstanceContextMode这将使得ConcurrencyMode无关。然而，随着PerCall你需要知道的MaxConcurrentInstances设置还有MaxConcurrentCalls的。根据您的绑定，您可能还需要与MaxConcurrentSessions财产予以关注。什么绑定您使用的主办这项服务？

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?

无论上述所有的，什么是错综复杂的二百分之一百六十测试跟着你的50/100的测试。

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