いくつかの WCF サービスで構成されるアプリケーションがあります。その一部は Workflow Foundation (.NET 3.5) で実装されており、その他は単純な C# です。これらのサービスは、パフォーマンス上の理由から、netNamedPipeBinding を介して相互に通信します。問題は、システムの負荷が増加するとすぐに、CommunicationExceptions とその下にある PipeExceptions がますます増えることです。面白いことに、これらのトランザクションは最終的に終了するように見えます。その理由の 1 つは、ワークフローに再試行メカニズムがあるためですが、WCF トレースにこれらのエラーが表示されていても、単純な C# サービスからの呼び出しでさえ成功します。Windows などの名前付きパイプ サブシステムに再試行メカニズムはありますか?
ただし、これらのエラーを修正するか、少なくとも根本的な問題を理解してください。アプリケーションのパフォーマンスと安定性に影響を与えているように感じます。サービス自体から発生する他の例外が見られない場合、これらのエラーの根本原因を正しく診断するにはどうすればよいですか?
ここに私が得る例外のいくつかがあります:
PipeException: パイプからの読み取り中にエラーが発生しました: パイプは終了しました。(109、0x6d)。
と：
PipeException: パイプが閉じられているため、操作を完了できません。これは、パイプの反対側のアプリケーションが終了したことが原因である可能性があります。
TimeoutException 内: パイプからの非同期読み取りが割り当てられたタイムアウト 00:02:00 内に完了しなかったため、パイプ接続が中止されました。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。
現在、タイムアウト例外は、システムが負荷の処理に問題を抱えているという事実から発生しているようです。これらの操作は通常非常に小さいですが、その量が問題のようです。それとも、これは以前のパイプ接続が終了し、プールに返されなかった結果でしょうか?
インスタンスの量などを増やすために、WCF 構成で serviceThrottling の動作を試してみましたが、これらのエラーが発生し続けています。任意のヒント？
/EDIT: WCF トレースとメッセージ ログの両方をオンにしました。そこに PipeExceptions と CommunicationExceptions が表示されます。アプリケーション自体はエラーを表示していません。log4net を使用してすべての例外がログに記録されるように、WCF サービスにかなりの機能を追加しました。これらのログにはエラーがまったく表示されません。これはすべてWCFレベルで起こっているようです。