IPC 性能：命名管道与套接字-IT科技

摘要：问题描述：似乎每个人都说命名管道比套接字 IPC 更快。它们快多少？我更喜欢使用套接字，因为它们可以进行双向通信并且非常灵活，但如果速度相差很大，我会选择速度而不是灵活性。解决方案 1：使用共享内存解决方案将获得最佳结果。命名管道仅比TCP 套接字好 16% 。通过IPC 基准测试获得结果：系统：Linux（...

问题描述：

似乎每个人都说命名管道比套接字 IPC 更快。它们快多少？我更喜欢使用套接字，因为它们可以进行双向通信并且非常灵活，但如果速度相差很大，我会选择速度而不是灵活性。

解决方案 1：

使用共享内存解决方案将获得最佳结果。

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

解决方案 2：

我建议你先走捷径，小心地隔离 IPC 机制，以便你可以从套接字更改为管道，但我肯定会先使用套接字。在进行预先优化之前，你应该确保 IPC 性能是一个问题。

如果您因为 IPC 速度而遇到麻烦，我认为您应该考虑切换到共享内存而不是管道。

如果您想做一些传输速度测试，您应该尝试socat，这是一个非常通用的程序，允许您创建几乎任何类型的隧道。

解决方案 3：

我同意 shodanex 的观点，你似乎过早地尝试优化一些尚未出现问题的东西。除非你知道套接字会成为瓶颈，否则我只会使用它们。

很多坚信命名管道的人发现这样做可以节省一点时间（取决于其他内容的编写水平），但最终代码在阻塞 IPC 回复上所花的时间比做有用的工作所花的时间还要多。当然，非阻塞方案有助于解决这个问题，但这些方案可能很棘手。我花了数年时间将旧代码带入现代时代，我可以说，在我见过的大多数情况下，加速几乎为零。

如果您真的认为套接字会降低您的速度，那么请开始使用共享内存，并仔细注意如何使用锁。同样，实际上，您可能会发现速度略有提高，但请注意，您正在浪费一部分时间等待互斥锁。我不会提倡去futex 地狱（好吧，2015 年已经不完全是地狱了，这取决于您的经验）。

总的来说，套接字（几乎）总是单片内核下用户空间 IPC 的最佳方式......并且（通常）最容易调试和维护。

解决方案 4：

请记住，套接字不一定意味着 IP（和 TCP 或 UDP）。您还可以使用 UNIX 套接字 (PF_UNIX)，与连接到 127.0.0.1 相比，它提供了明显的性能提升

解决方案 5：

通常，数字比感觉更能说明问题，这里有一些数据：
管道与 Unix 套接字性能（opendmx.net）。

该基准测试显示管道速度提高了约 12% 至 15%。

解决方案 6：

您可以在这里找到可运行的工作台https://github.com/goldsborough/ipc-bench

在此处输入图片描述

问候

解决方案 7：

如果您不需要速度，那么套接字是最简单的方法！

如果您关注的是速度，最快的解决方案是共享内存，而不是命名管道。

解决方案 8：

对于与命名管道的双向通信：

如果进程较少，可以为两个方向打开两个管道（processA2ProcessB 和 processB2ProcessA）
如果您有许多进程，您可以为每个进程打开输入和输出管道（processAin，processAout，processBin，processBout，processCin，processCout等）
或者你可以像往常一样采用混合方式:)

命名管道非常容易实现。

例如，我用命名管道在 C 中实现了一个项目，得益于基于标准文件输入输出的通信（fopen、fprintf、fscanf……），它非常简单和干净（如果这也是一个考虑因素的话）。

我甚至用 Java 对它们进行编码（我正在对它们进行序列化并通过它们发送对象！）

命名管道有一个缺点：

由于它们依赖于文件系统（假设共享文件系统不是一种选择），因此它们不能像套接字那样在多台计算机上扩展

解决方案 9：

套接字的一个问题是它们没有办法刷新缓冲区。有一种称为 Nagle 算法的东西，它收集所有数据并在 40 毫秒后刷新。因此，如果是响应能力而不是带宽，那么使用管道可能更好。

您可以使用套接字选项 TCP_NODELAY 禁用 Nagle，但读取端将永远不会在一次读取调用中收到两条短信。

因此测试它，我最终没有得到这些，而是在共享内存中使用 pthread 互斥和信号量实现了基于内存映射的队列，避免了大量的内核系统调用（但今天它们不再很慢了）。

解决方案 10：

我知道这是一个非常老的线程，但它很重要，所以我想补充一点。UDS 在本地 IPC 的概念上要快得多。它们不仅速度更快，而且如果您的内存控制器支持 DMA，那么 UDS 几乎不会对您的 CPU 造成任何负载。DMA 控制器只会为 CPU 卸载内存操作。TCP 需要被打包成大小为 MTU 的块，如果您没有智能网卡或 TCP 卸载到专用硬件的某个地方，这会对 CPU 造成相当大的负载。根据我的经验，UDS 在现代系统上的延迟和吞吐量都快了大约 5 倍。

这些基准测试来自这个简单的基准测试代码。自己尝试一下。它还支持 UDS、管道和 TCP： https ://github.com/rigtorp/ipc-bench

对我来说当地的基准