Low Throughput on Windows Named Pipe Over WAN_问答_开发者

Low Throughput on Windows Named Pipe Over WAN

开发者 https://www.devze.com 2022-12-28 00:09 出处：网络

I\'m having problems with low performance using a Windows named pipe. The throughput drops off rapidly as the network la开发者_运维问答tency increases. There is a roughly linear relationship between m

I'm having problems with low performance using a Windows named pipe. The throughput drops off rapidly as the network la开发者_运维问答tency increases. There is a roughly linear relationship between messages sent per second and round trip time. It seems that the client must ack each message before the server will send the next one. This leads to very poor performance, I can only send 5 (~100 byte) messages per second over a link with an RTT of 200 ms.

The pipe is asynchronous, using multiple overlapped write operations (and multiple overlapped reads at the client end), but this is not improving throughput. Is it possible to send messages in parallel over a named pipe? The pipe is created using PIPE_TYPE_MESSAGE, would PIPE_READMODE_BYTE work better? Is there any other way I can improve performance?

This is a deployed solution, so I can't simply replace the pipe with a socket connection (I've read that Windows named pipe aren't recommended for use over a WAN, and I'm wondering if this is why). I'd be grateful for any help with this matter.

We found that Named Pipes had poor performance from Windows XP onwards.

I don't have a solution for you. But I am concurring with the notion of Named Pipes being useless from XP onwards. We changed our software (in terms of IPC) completely because of it.

Is your comms factored into a separate DLL? Perhaps you could replace the DLL with an interface that looks the same but behaves differently?

I've implemented a work around, introducing a small (~1ms) fixed delay to buffer up as much data as possible before writing to the pipe. Over a network link with a RTT of 200ms, I can send ten times as much data in about a third of the time.

I send a message down the pipe when it first connects, so the client can determine the comms mode supported by the server and send data accordingly.

I would imagine that some of the WAN optimisation gear out there would be able to boost performance, as one of the things they do is understand protocols and reduce their chattiness. Given the latency of many WAN links, this alone can boost throughput and reduce timeouts.