IPC 성능 : 명명 된 파이프 대 소켓

IPC 성능 : 명명 된 파이프 대 소켓

---

모든 사람들은 명명 된 파이프가 소켓 IPC보다 빠르다고 말하는 것 같습니다. 얼마나 빠릅니까? 나는 양방향 통신을 할 수 있고 매우 유연하기 때문에 소켓을 사용하는 것을 선호하지만 상당한 양이라면 유연성보다 속도를 선택할 것입니다.

---

소켓에서 파이프로 변경할 수 있도록 ipc 메커니즘을 신중하게 분리하여 쉬운 경로를 먼저 선택하는 것이 좋지만 소켓을 먼저 사용하겠습니다. 선제 적으로 최적화하기 전에 IPC 성능이 문제인지 확인해야합니다.

그리고 IPC 속도로 인해 문제가 발생하면 파이프 대신 공유 메모리로 전환하는 것을 고려해야한다고 생각합니다.

전송 속도 테스트를 수행 하려면 거의 모든 종류의 터널을 생성 할 수있는 매우 다재다능한 프로그램 인 socat 을 시도해야합니다 .

---

나는 shodanex에 동의 할 것입니다. 아직 문제가되지 않는 것을 최적화하려고 조기에 시도하고있는 것 같습니다. 소켓이 병목 현상이 될 것이라는 것을 알지 못한다면 그냥 사용하겠습니다.

명명 된 파이프로 맹세하는 많은 사람들은 (다른 모든 것이 얼마나 잘 작성되었는지에 따라) 약간의 절약 효과를 얻지 만 유용한 작업을 수행하는 것보다 IPC 응답을 차단하는 데 더 많은 시간을 소비하는 코드로 끝납니다. 물론 비 차단 방식이 도움이되지만 까다로울 수 있습니다. 오래된 코드를 현대로 가져 오는 데 몇 년을 보내면 내가 본 대부분의 경우 속도 향상이 거의 없다고 말할 수 있습니다.

소켓이 당신의 속도를 늦출 것이라고 정말로 생각한다면, 잠금을 사용하는 방법에주의를 기울이고 공유 메모리를 사용하여 게이트 밖으로 나가십시오. 다시 말하지만 실제로는 약간의 속도 향상이있을 수 있지만 상호 배제 잠금을 기다리는 데 일부를 낭비하고 있음을 알 수 있습니다. 나는 여행 옹호하지 않을거야 퓨 텍스 지옥 (음, 확실히 당신의 경험에 따라, 2015 년에 더 이상 지옥).

파운드의 경우 소켓은 (거의) 항상 모 놀리 식 커널 아래에서 사용자 공간 IPC로 이동하는 가장 좋은 방법이며 (보통) 디버깅 및 유지 관리가 가장 쉽습니다.

---

소켓이 반드시 IP (및 TCP 또는 UDP)를 의미하는 것은 아닙니다. UNIX 소켓 (PF_UNIX)을 사용하여 127.0.0.1에 연결하는 것보다 눈에 띄는 성능 향상을 제공 할 수도 있습니다.

---

숫자는 느낌보다 더 많은 것을 말합니다. 여기 데이터가 있습니다 : Pipe vs Unix Socket Performance (opendmx.net) .

이 벤치 마크는 파이프의 경우 약 12 ​​~ 15 % 더 빠른 속도의 차이를 보여줍니다.

---

공유 메모리 솔루션으로 얻을 수있는 최상의 결과 .

명명 된 파이프 는 TCP 소켓 보다 16 % 만 우수 합니다.

IPC 벤치마킹으로 결과를 얻습니다 .

• 시스템 : Linux (Linux ubuntu 4.4.0 x86_64 i7-6700K 4.00GHz)
• 메시지 : 128 바이트
• 메시지 수 : 1000000

파이프 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     27367.454 ms
Average duration:   27.319 us
Minimum duration:   5.888 us
Maximum duration:   15763.712 us
Standard deviation: 26.664 us
Message rate:       36539 msg/s

FIFO (이름이 지정된 파이프) 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     38100.093 ms
Average duration:   38.025 us
Minimum duration:   6.656 us
Maximum duration:   27415.040 us
Standard deviation: 91.614 us
Message rate:       26246 msg/s

Message Queue 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     14723.159 ms
Average duration:   14.675 us
Minimum duration:   3.840 us
Maximum duration:   17437.184 us
Standard deviation: 53.615 us
Message rate:       67920 msg/s

공유 메모리 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     261.650 ms
Average duration:   0.238 us
Minimum duration:   0.000 us
Maximum duration:   10092.032 us
Standard deviation: 22.095 us
Message rate:       3821893 msg/s

TCP 소켓 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     44477.257 ms
Average duration:   44.391 us
Minimum duration:   11.520 us
Maximum duration:   15863.296 us
Standard deviation: 44.905 us
Message rate:       22483 msg/s

Unix 도메인 소켓 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     24579.846 ms
Average duration:   24.531 us
Minimum duration:   2.560 us
Maximum duration:   15932.928 us
Standard deviation: 37.854 us
Message rate:       40683 msg/s

ZeroMQ 벤치 마크 :

Message size:       128
Message count:      1000000
Total duration:     64872.327 ms
Average duration:   64.808 us
Minimum duration:   23.552 us
Maximum duration:   16443.392 us
Standard deviation: 133.483 us
Message rate:       15414 msg/s

---

속도가 필요하지 않으면 소켓이 가장 쉬운 방법입니다!

If what you are looking at is speed, the fastest solution is shared Memory, not named pipes.

---

For two way communication with named pipes:

• If you have few processes, you can open two pipes for two directions (processA2ProcessB and processB2ProcessA)
• If you have many processes, you can open in and out pipes for every process (processAin, processAout, processBin, processBout, processCin, processCout etc)
• Or you can go hybrid as always :)

Named pipes are quite easy to implement.

E.g. I implemented a project in C with named pipes, thanks to standart file input-output based communication (fopen, fprintf, fscanf ...) it was so easy and clean (if that is also a consideration).

I even coded them with java (I was serializing and sending objects over them!)

Named pipes has one disadvantage:

• they do not scale on multiple computers like sockets since they rely on filesystem (assuming shared filesystem is not an option)

---

One problem with sockets is that they do not have a way to flush the buffer. There is something called the Nagle algorithm which collects all data and flushes it after 40ms. So if it is responsiveness and not bandwidth you might be better off with a pipe.

You can disable the Nagle with the socket option TCP_NODELAY but then the reading end will never receive two short messages in one single read call.

So test it, i ended up with none of this and implemented memory mapped based queues with pthread mutex and semaphore in shared memory, avoiding a lot of kernel system calls (but today they aren't very slow anymore).

---

Named pipes and sockets are not functionally equivalent; sockets provide more features (they are bidirectional, for a start).

We cannot tell you which will perform better, but I strongly suspect it doesn't matter.

Unix domain sockets will do pretty much what tcp sockets will, but only on the local machine and with (perhaps a bit) lower overhead.

If a Unix socket isn't fast enough and you're transferring a lot of data, consider using shared memory between your client and server (which is a LOT more complicated to set up).

Unix and NT both have "Named pipes" but they are totally different in feature set.

---

You can use lightweight solution like ZeroMQ [ zmq/0mq ]. It is very easy to use and dramatically faster then sockets.

참고URL : https://stackoverflow.com/questions/1235958/ipc-performance-named-pipe-vs-socket