Windows上的低吞吐量通过WAN命名的管道

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

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

这是一个已部署的解决方案，所以我不能简单地用套接字连接替换管道（我读过Windows命名管道不推荐用于WAN，我想知道这是否为什么）。我会很感激这件事的任何帮助。

来源

2010-04-26 MichaelB76

重叠I/O只意味着WriteFile立即将控制权返回给您的应用程序。它不会影响实际的广域网流量。 – MSalters 2010-04-26 15:41:11

是的，我明白这一点，谢谢。然而，我很惊讶地发现，在管道发送任何更多数据之前，每个写入事件都需要来自客户端的确认，并且我试图找到解决办法。 – MichaelB76 2010-04-27 11:19:40

我已经实施了一项解决方案，在写入管道之前引入一个小的（〜1ms）固定延迟以缓冲尽可能多的数据。在RTT为200ms的网络链接上，我可以在大约三分之一的时间内发送十倍的数据。

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

来源

2010-05-05 09:36:20 MichaelB76

我们发现命名管道有poor performance from Windows XP起。

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

你的comms是否考虑到了单独的DLL？也许你可以用一个看起来相同但行为不同的接口替换DLL。

来源

2010-04-28 20:30:28

您在该链接中的回答提到您将其替换为您自己的共享内存数据传输实施。您是否发现管道在网络上表现不佳，或者您是否仅仅将它们用于本地IPC？ – MichaelB76 2010-04-29 09:45:38

主要供本地IPC使用。我不记得细节，那是几年前。我想我们也简单地看过网络的东西。但是，如果它本地的贫困，它可能会在网络上变得更糟。我们进行了一些搜索，以查明其他人是否有命名管道问题，并确信他们确实没有解决方案，这就是为什么我们完全改变了方向。共享内存解决方案非常出色，但它将我们的软件捆绑在一台机器上，而不是整个网络上： - （幸运的是，对我们来说，我们大多数客户都希望在一台机器上工作。） – 2010-04-29 13:54:07

有趣，但不幸的是，并没有帮助我解决问题，我们有一个部署的解决方案，由3个大洲的46台服务器组成，使用IPC的命名管道。 – MichaelB76 2010-05-05 09:38:29

我可以想象，一些广域网优化设备可以提升性能，因为他们所做的一件事情就是了解协议并降低它们的烦琐程度。考虑到许多WAN链路的延迟，仅此一项就可以提高吞吐量并减少超时。

来源

2011-03-08 10:19:46 mdubash

Windows上的低吞吐量通过WAN命名的管道

回答

相关问题