3

負荷テスト中にサービスの 1 つで呼び出しをすばやく開始すると、エラーが発生するという問題があります。

「System.ServiceModel.ServerTooBusyException: 信頼できるセッションを作成する要求が RM 送信先によって拒否されました。サーバー 'net.tcp://localhost:10511/ParameterMonitorService' がビジー状態のため、この要求を処理できません。後でもう一度試してください。チャネル開けられなかった。"

maxPendingChannels の値をデフォルトの 4 から 128 に増やしたところ、エラーはなくなりましたが、サービスは例外をスローするのではなく、負荷がかかっているメッセージの処理を停止し、数分後に再開します。

何もドロップしないようで、しばらくハングします。サービスを強化すればするほど、この回復には時間がかかるようです。

このサービスは、ConcurrencyMode Multiple の Per-Call として構成されています。その他の動作設定は次のとおりです。

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

私たちはちょっと立ち往生しています。どんな助けでも大歓迎です！

4

2 に答える 2

2

これは古典的なパフォーマンス チューニングの話です。信頼できるセッションでスロットルを再構成することにより、システムのボトルネックであったものを取り除き、ボトルネックをシステムの別の場所に移動しました。

サービスがどのようにホストされているか、どのハードウェアで何を行っているか、どのようにそれを行っているかなどの詳細がなければ、ボトルネックが現在どこにあるのかを人々が診断してくれるとは期待できません。Windows パフォーマンス モニター カウンターを使用して、できる限り包括的にシステムを計測し、これらを解釈して、システム内でリソースの競合が現在発生している場所を把握する必要があります。

私の最初の推測では、セッション スロットルを削除した後の同時実行性の増加がマネージド スレッド プール スレッドの競合を引き起こしていると思われますが、これは推測にすぎません。実際には、推測ではなく、証拠に基づいて診断する必要があります。

于 2011-02-22T10:50:54.707 に答える