IPC速度和比较

Question

我试图实现一个涉及不同模块间IPC的实时应用程序。这些模块正在进行一些数据密集型处理。在原型中，我使用消息队列作为IPC的支柱(Activemq)，这很容易(考虑到我完全是IPC新手)，但速度非常慢。

这是我的情况:

• 我已经隔离了IPC部分，以便将来可以用其他方式改变它。
• 我有3周时间来实现另一个更快的版本。:(
• IPC应该是快速的，但也相对容易学习

我一直在研究不同的IPC方法：套接字、管道、共享内存。然而，我没有IPC方面的经验，绝不能在3周内失败...哪种IPC是安全的起点？

谢谢。 Lily

- Lily

Answer 1

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

最近我遇到了同样的IPC基准测试。我认为我的结果将对所有想比较IPC性能的人有用。

管道基准测试：

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

- chronoxor

Answer 2

我自己也面临类似的问题。

我发现以下页面很有帮助- IPC性能：命名管道与套接字（特别是）和Windows本地IPC的套接字vs命名管道？。

听起来，如果您真的关心性能，共享内存是应该采用的方式，但如果您当前拥有的系统是消息队列，则可能是一种...不同的结构。套接字和/或命名管道可能更容易实现，如果任何一个符合您的规格，则完成了。

- Arandia

Answer 3

你可以查看这篇博客文章https://publicwork.wordpress.com/2016/07/17/endurox-vs-zeromq/。基本上，它比较了建立在POSIX队列（内核队列IPC）上的Enduro/X和可以同时在几个不同的传输类别上传递消息的ZeroMQ，包括tcp://（网络套接字），ipc://，inproc://，pgm://和epgm://用于组播。从图表中可以看出，在使用较大的数据包时，运行在队列上的Enduro/X胜过套接字。两个系统都可以以每秒约400,000条消息的速度运行良好，但是对于5KB的消息，内核队列运行得更好。

（图片来源：https://publicwork.wordpress.com/2016/07/17/endurox-vs-zeromq/）

---

更新： 针对下面的评论，我重新运行了测试以在ipc://上运行ZeroMQ，见图片：

正如我们所见，ZeroMQ的ipc://更好，但在某些范围内，Enduro/X显示出更好的结果，然后又被ZeroMQ取代。

因此，我可以说IPC的选择取决于您计划执行的工作。

请注意，ZeroMQ IPC运行在POSIX管道上。而Enduro/x运行在POSIX队列上。

- Madars Vi

---

请允许我问一下，您是否注意到引用的测试/比较并没有在相同的传输类上使用ZeroMQ（试图将**tcp://与ipc://进行比较）？您能否提供一个公正的苹果对苹果的比较结果，其中Enduro/X和ZeroMQ都使用IPC**？ - user3666197

请参见上方，我已经使用ipc://重新进行了测试。 - Madars Vi

+1 为关注加分。在多个传输类混合的分布式系统中处理二进制大对象（ BLOBs ）的情况下，Enduro/X 如何工作？这些传输类包括 tcp://（用于群集分布式 SIGs）、inproc://（用于最快/最低延迟的进程间消息传递）和 epgm://（用于最终内容流）。性能扩展是如何实现的——一旦添加了2、4、8、16、32、64、128、256、512、1024 个对等体到给定数量的 I/O 线程下（.Context() 引擎可以操作）？ - user3666197

Enduro/X使用TCP协议来桥接多达32个集群服务器节点。每个集群节点在进程之间进行本地IPC（如上图所示）。这些进程是由应用服务器控制的单独可执行副本（因此如果任何二进制文件死亡，可以提供负载平衡和容错性）。Enduro/X不执行任何多播形式（除了XATMI服务的订阅/发布事件范例）。因此，如果需要为终端设备进行多播，则开发人员需要创建适配器XATMI服务器或客户端，以便自行进行EPGM流传输。请在此处查看自述文件：https://github.com/endurox-dev/endurox - Madars Vi

为了满足用户3666197的需求，您可以将Enduro/X作为应用服务器，使用ipc://和tcp://传输。而对于epgm://，您可以使用ZeroMQ。这两个系统都支持BLOB处理。 - Madars Vi

Answer 4

在Windows系统中，您可以使用WM_COPYDATA，这是一种特殊的基于共享内存的IPC技术。这是一种古老但简单的技术：发送方（进程A）发送一条消息，其中包含指向其内存中某些数据的指针，并等待接收方（进程B）处理该消息，例如创建数据的本地副本。这种方法非常快速，并且在Windows 8 Developer Preview上也可以使用（请参见我的基准测试）。通过在发送方进行序列化并在接收方进行反序列化，可以以任何形式传输数据。还可以轻松实现发送方和接收方消息队列，使通信异步化。

- kol

---

根据您的基准测试，我很好奇为什么Win7的性能如此糟糕。 - stanleyxu2005

因为它是一台配备相对较慢的单核Atom CPU的上网本。 - kol