WCF 可靠消息传递 : stuttering service after maxPendingChannels increase

Question

我们有一个问题，即在负载测试期间，如果我们在我们的一项服务上快速触发调用，我们会收到错误

“System.ServiceModel.ServerTooBusyException:创建可靠 session 的请求已被 RM 目标拒绝。服务器 'net.tcp://localhost:10511/ParameterMonitorService' 太忙，无法处理此请求。稍后再试. channel 打不开。”

我们将 maxPendingChannels 的值从其默认值 4 增加到 128 甚至更高，错误消失了，但是现在，服务不会抛出异常，而是会在负载下停止处理消息，然后在几分钟后重新开始.

好像什么都没掉，只是挂了一会儿。我们对服务的冲击越大，恢复所需的时间就越长。

该服务配置为 Per-Call with ConcurrencyMode Multiple。其他行为设置是:

<serviceThrottling maxConcurrentCalls="100" maxConcurrentSessions="100" maxConcurrentInstances="100"/>

<customBinding>

    <binding name="Services_Custom_Binding" openTimeout="00:00:20" sendTimeout="00:01:00">          
        <reliableSession  ordered="true" inactivityTimeout="00:10:00" maxPendingChannels="128" flowControlEnabled="true" />
        <binaryMessageEncoding>
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
            maxBytesPerRead="4096" maxNameTableCharCount="16384" />            
        </binaryMessageEncoding>
        <tcpTransport maxPendingConnections="100" listenBacklog="100" />          
      </binding>
  </customBinding>

我们有点卡住了。任何帮助表示赞赏!

Answer 1

这是一个经典的性能调优故事。通过重新配置可靠 session 的限制，您已经消除了系统中曾经的瓶颈，并将瓶颈转移到系统中的其他地方。

你真的不能指望人们凭空诊断出现在的瓶颈在哪里，而没有任何关于你的服务是如何托管的，在什么硬件上，它在做什么，或者它是如何做的细节它。您需要尽可能全面地检测您的系统，使用 Windows 性能监视器计数器，并解释这些计数器以了解系统中现在发生资源争用的位置。

我的第一个猜测是移除 session 限制后增加的并发性导致了对托管线程池线程的争用，但这只是一个猜测——你真的想根据证据而不是猜测来进行诊断。