Windows Named Pipe Over WAN 上的低吞吐量答案

【问题标题】：Low Throughput on Windows Named Pipe Over WANWindows Named Pipe Over WAN 上的低吞吐量
【发布时间】：2010-04-26 13:48:01
【问题描述】：

我在使用 Windows 命名管道时遇到了性能低下的问题。随着网络延迟的增加，吞吐量迅速下降。每秒发送的消息与往返时间之间存在大致线性关系。似乎客户端必须在服务器发送下一条消息之前确认每条消息。这会导致性能非常差，我每秒只能通过 RTT 为 200 毫秒的链接发送 5 条（约 100 字节）消息。

管道是异步的，使用多个重叠的写入操作（以及客户端的多个重叠读取），但这并没有提高吞吐量。是否可以通过命名管道并行发送消息？管道是使用 PIPE_TYPE_MESSAGE 创建的，PIPE_READMODE_BYTE 会更好吗？有没有其他方法可以提高性能？

这是一个已部署的解决方案，所以我不能简单地用套接字连接替换管道（我读过不建议在 WAN 上使用 Windows 命名管道，我想知道这是否是原因)。对于此事，我将不胜感激。

【问题讨论】：

【解决方案1】：

我们发现命名管道具有poor performance from Windows XP 之后的名称。

我没有适合你的解决方案。但我同意命名管道从 XP 开始就无用的概念。我们完全改变了我们的软件（就 IPC 而言）。

您的通讯是否被分解到一个单独的 DLL 中？也许您可以用一个看起来相同但行为不同的接口替换 DLL？

【讨论】：

您在该链接中的回答提到您将它们替换为您自己的共享内存数据传输实现。您是否发现管道在网络上表现不佳，或者您只是将它们用于本地 IPC？
主要用于本地 IPC。不记得细节了，那是几年前的事了。我想我们也简要地研究了网络的东西。但如果它在本地很差，它可能会在网络上变得更糟。我们进行了一些搜索，以查找其他人是否对命名管道有问题，果然他们确实有，但没有人有解决方案，这就是我们完全改变策略的原因。共享内存解决方案非常棒，但它将我们的软件绑定在一台机器上而不是通过网络工作:-( 幸运的是，我们的大多数客户都希望在一台机器上工作。
有趣，但不幸的是，这并不能帮助我解决这个问题。我们部署了一个解决方案，由遍布 3 大洲的 46 台服务器组成，使用 IPC 命名管道。

【解决方案2】：

我已经实施了一项变通方案，在写入管道之前引入了一个小的 (~1ms) 固定延迟来缓冲尽可能多的数据。通过 RTT 为 200 毫秒的网络链接，我可以在大约三分之一的时间内发送十倍的数据。

我在管道第一次连接时发送一条消息，以便客户端可以确定服务器支持的通信模式并相应地发送数据。

【讨论】：

【解决方案3】：

我想一些 WAN 优化设备将能够提高性能，因为它们所做的事情之一就是了解协议并减少它们的闲聊。考虑到许多 WAN 链接的延迟，仅此一项就可以提高吞吐量并减少超时。

【讨论】：