WCF：如何识别待处理的HTTP请求

Question

观察到的行为（示例）：

当向我的WCF服务发送100个HTTP请求时，WCF框架仅接收和发送11个请求，因为我的后端代码一次将并发处理限制为10个请求。

根据Fiddler的说法，第12个HTTP请求实际上甚至没有在传输层接收。

我为服务器端的每个请求模拟了5秒的处理时间。一旦处理了前10个请求中的一个并且第11个请求的处理已经开始，就会从网络套接字读取第12个请求。

问题

我想监控当前有多少请求待处理。最终，我想在队列超过一定限制后拒绝新的请求。

测试设置

WCF服务配置如下（PSEUDO代码）：

ServiceBehaviorAttribute.ConcurrencyMode = ConcurrencyMode.Multiple
ServiceBehaviorAttribute.InstanceContextMode = InstanceContextMode.Single
ServiceThrottlingBehavior.MaxConcurrentCalls = int.MaxValue
ServiceThrottlingBehavior.MaxConcurrentInstances = int.MaxValue
ServiceThrottlingBehavior.MaxConcurrentSessions= int.MaxValue

此外，我添加了一个自定义合约行为来应用我自己的固定大小的线程池进行请求处理（使用.NET线程池时行为几乎相同）：

    void IContractBehavior.ApplyDispatchBehavior(
        ContractDescription contractDescription, 
        ServiceEndpoint endpoint, 
        DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.SynchronizationContext = SYNCHRONIZER;
    }

其中SYNCHRONIZER是一个派生自SynchronizationContext并覆盖＆＃34; Post＆＃34;的类。实际排队工作项的方法。

注释

• 我测试了客户端：同时向服务发送100个HTTP请求没有问题。如果我将服务器端工作线程计数增加到100，则所有请求都会立即传输，整个测试执行时间为5秒。
• Windows性能计数器＆＃34;呼叫未完成＆＃34;来自System.ServiceModel显示调度的请求的数量（因此它没用）。
• 我试图附加不同的性能分析器。但他们没有引导我进入线程阻止请求接收的神秘代码位置。

有人可以解释观察到的行为吗？