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

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

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

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

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

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

명명 된 파이프 는 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

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

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

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

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

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

종종 숫자는 느낌보다 더 많은 것을 말합니다. 여기에 몇 가지 데이터가 있습니다. 파이프 대 Unix 소켓 성능 (opendmx.net) .

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

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

보고있는 것이 속도 인 경우 가장 빠른 솔루션은 명명 된 파이프가 아닌 공유 메모리입니다.

명명 된 파이프와의 양방향 통신 :

• 프로세스가 적은 경우 두 방향 (processA2ProcessB 및 processB2ProcessA)에 대해 두 개의 파이프를 열 수 있습니다.
• 프로세스가 많은 경우 모든 프로세스 (processAin, processAout, processBin, processBout, processCin, processCout 등)에 대해 파이프를 열고 내보낼 수 있습니다.
• 또는 항상 하이브리드로 갈 수 있습니다 :)

명명 된 파이프는 구현하기가 매우 쉽습니다.

예를 들어, 표준 파일 입출력 기반 통신 (fopen, fprintf, fscanf ...) 덕분에 명명 된 파이프를 사용하여 C로 프로젝트를 구현했습니다. 너무 쉽고 깔끔했습니다 (이것도 고려 사항 인 경우).

나는 그것들을 자바로 코딩하기도했다 (나는 그것들을 직렬화하고 객체를 보냈다!)

명명 된 파이프에는 한 가지 단점이 있습니다.

• 파일 시스템에 의존하기 때문에 소켓과 같은 여러 컴퓨터에서 확장되지 않습니다 (공유 파일 시스템이 옵션이 아니라고 가정).

소켓의 한 가지 문제점은 버퍼를 플러시 할 방법이 없다는 것입니다. 모든 데이터를 수집하고 40ms 후에 플러시하는 Nagle 알고리즘이라는 것이 있습니다. 따라서 대역폭이 아니라 응답 성이라면 파이프를 사용하는 것이 더 나을 수 있습니다.

소켓 옵션 TCP_NODELAY를 사용하여 Nagle을 비활성화 할 수 있지만 읽기 끝은 단일 읽기 호출에서 두 개의 짧은 메시지를 수신하지 않습니다.

그래서 그것을 테스트하고, 나는 이것으로 끝나지 않았고 공유 메모리에 pthread 뮤텍스와 세마포어를 사용하여 메모리 매핑 기반 큐를 구현하여 많은 커널 시스템 호출을 피했습니다 (그러나 오늘날 더 이상 느리지 않습니다).

명명 된 파이프와 소켓은 기능적으로 동일하지 않습니다. 소켓은 더 많은 기능을 제공합니다 (시작을 위해 양방향).

어느 쪽이 더 나은지 말할 수는 없지만 중요하지 않다고 생각합니다.

유닉스 도메인 소켓은 tcp 소켓이하는 일을 거의 수행하지만 로컬 머신에서만 (아마도 약간) 더 낮은 오버 헤드를 가지고 있습니다.

Unix 소켓이 충분히 빠르지 않고 많은 데이터를 전송하는 경우 클라이언트와 서버간에 공유 메모리를 사용하는 것이 좋습니다 (설정하기가 훨씬 더 복잡함).

Unix와 NT는 모두 "Named pipes"를 가지고 있지만 기능 세트가 완전히 다릅니다.

ZeroMQ [ zmq / 0mq ] 와 같은 경량 솔루션을 사용할 수 있습니다 . 사용하기 매우 쉽고 소켓보다 훨씬 빠릅니다.