我有一个由几个 WCF 服务组成的应用程序，其中一些是在 Workflow Foundation (.NET 3.5) 中实现的，其他的只是普通的 C#。出于性能原因，这些服务通过 netNamedPipeBinding 相互通信。问题是，一旦系统负载增加，我就会看到越来越多的 CommunicationExceptions 和底层 PipeExceptions。有趣的是，这些交易似乎最终完成了。原因之一是我们在工作流中有重试机制，但即使来自普通 C# 服务的调用也会成功，即使我在 WCF 跟踪中看到这些错误。Windows的命名管道子系统中有一些重试机制吗？
但是，我希望修复这些错误，或者至少了解潜在的问题。我觉得它们正在影响应用程序的性能和稳定性。如果我没有看到来自服务本身的任何其他异常，我该如何正确诊断这些错误的根本原因？
以下是我得到的一些例外情况：
PipeException： 从管道读取错误：管道已结束。(109, 0x6d)。
和：
PipeException： 操作无法完成，因为管道已关闭。这可能是由于管道另一端的应用程序退出造成的。
在 TimeoutException 内： 管道连接被中止，因为从管道的异步读取未在分配的 00:02:00 超时内完成。分配给此操作的时间可能是较长超时的一部分。
现在超时异常似乎来自系统无法处理负载的事实。这些操作通常很小，但它们的数量似乎是问题所在。或者这可能是以前的管道连接被终止并且没有返回到池中的结果？
我尝试在 WCF 配置中尝试使用 serviceThrottling 行为来增加实例数量等，但这些错误不断出现。有小费吗？
/编辑：我确实打开了 WCF 跟踪和消息日志记录。这就是我看到 PipeExceptions 和 CommunicationExceptions 的地方。应用程序本身没有显示任何错误。我们已经对 WCF 服务进行了相当多的检测，以便使用 log4net 记录所有异常，并且我在这些日志中根本看不到任何错误。这一切似乎都发生在 WCF 级别。