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命名的管道

回答

相關問題