【发布时间】：2011-04-13 15:12:38
【问题描述】：
我有一个由多个 WCF 服务组成的应用程序，其中一些是在 Workflow Foundation (.NET 3.5) 中实现的，其他的只是普通的 C#。出于性能原因，这些服务通过 netNamedPipeBinding 相互通信。问题在于，一旦系统负载增加，我就会看到越来越多的 CommunicationExceptions 和底层 PipeExceptions。有趣的是，这些交易似乎最终完成了。原因之一是我们在工作流中有重试机制，但即使来自普通 C# 服务的调用也会成功，即使我在 WCF 跟踪中看到这些错误。 Windows的命名管道子系统中是否有一些重试机制？
但是，我希望修复这些错误，或者至少了解根本问题。我觉得它们正在影响应用程序的性能和稳定性。如果我没有看到来自服务本身的任何其他异常，我该如何正确诊断这些错误的根本原因？
以下是我得到的一些例外情况：
PipeException： 从管道读取错误：管道已结束。 (109, 0x6d)。
还有：
PipeException： 操作无法完成，因为管道已关闭。这可能是由于管道另一端的应用程序退出造成的。
在 TimeoutException 内： 管道连接被中止，因为从管道的异步读取未在分配的 00:02:00 超时内完成。分配给此操作的时间可能是较长超时的一部分。
现在超时异常似乎来自系统在处理负载时遇到问题。这些操作通常很小，但它们的数量似乎是问题所在。或者这可能是以前的管道连接被终止并且没有返回到池中的结果？
我尝试在 WCF 配置中尝试使用 serviceThrottling 行为来增加实例数量等，但这些错误不断出现。有什么建议吗？
/EDIT：我确实打开了 WCF 跟踪和消息记录。这就是我看到 PipeExceptions 和 CommunicationExceptions 的地方。应用程序本身没有显示任何错误。我们已经对 WCF 服务进行了相当多的检测，以便使用 log4net 记录所有异常，并且我在这些日志中根本看不到任何错误。这一切似乎都发生在 WCF 级别。
【问题讨论】：
-
我们最终发现WCF net.pipe堆栈存在问题。我们更改为 basicHttp 绑定，除了所有错误消失之外，服务调用速度至少提高了一倍。真的很奇怪。
-
您最终是如何发现这一点的？我遇到了类似的问题，但我还没有准备好跳船到 basicHttp。
-
@ColeW whoo，这是一个老问题，我必须重新挖掘我的记忆。我想我们在区域主管邮件列表上得到了一些反馈，我的同事是一个 RD，net.pipe 堆栈在高负载下不稳定，在使用 basicHttp 测试后，我们得到了更好的吞吐量和更稳定的服务。我早就放弃了 WCF，所以我不确定当前的状态。很遗憾听到您仍然遇到同样的问题。
-
是的，这是一个非常古老的问题！实际上，出于类似的原因，我们放弃了 wcf net.tcp 绑定，因此这是我们在同一台机器上的两个应用程序之间进行通信的第二个绑定。Wcf 似乎并不是它的全部内容。我们可能不得不最终切换到 basicHttp。奇怪的是，我在本地机器上的所有测试结果都很好。我可以将服务提高 10 倍和 10 倍多次，并且不会出错。
标签： .net-3.5 wcf workflow-foundation netnamedpipebinding