代码之家 › 专栏 › 技术社区 › Yodan Tauber

本地IPC的平均性能测量

rpc ipc tcp sockets performance

3

Yodan Tauber · 技术社区 · 15 年前

我们现在正在评估当前项目的不同IPC(或者更确切地说RPC)方法,该项目正处于早期阶段。性能是个大问题,所以我们正在做一些测量来帮助我们做出选择。我们沟通的过程将 在同一台机器上 .

另一个有效的选择是完全避免使用IPC(将其中一个进程的特性封装在一个.NET DLL中,并让另一个进程使用它),但这是我们真正希望避免的一个选择,因为这两个软件是由两个独立的公司开发的,我们发现保持良好的“屏障”非常重要,他们是好邻居。

我们的测试包括使用每种方法跨流程边界传递消息(其中包含各种大小的blob)。这些是我们得到的数据(性能范围与消息大小范围相关):

Web服务(SOAP over HTTP):
- 25-30 MB/秒 二进制数据编码为Base64时(默认)
- 70-100 MB/秒 使用MTOM时
.NET远程处理(TCP上的BinaryFormatter): 100-115兆字节/秒
控制组-DLL方法调用+mem copy: 800-1000 MB/秒

现在,我们到处寻找这些(和其他)IPC方法的一些平均性能数据,包括原始TCP环回套接字的性能,但找不到任何数据。这些数字看起来正常吗?为什么这些本地IPC方法的性能至少比复制内存慢10倍?即使使用原始套接字,我也无法获得更好的结果-TCP的开销有那么大吗?

3 回复 | 直到 15 年前

1

3

Maxim Egorushkin 15 年前

共享内存是最快的。

生产者进程可以将其输出放入进程之间共享的内存中,并通知其他进程共享数据已更新。在Linux上,您自然地将互斥量和条件变量放在同一个共享内存中,以便其他进程可以等待条件变量的更新。

2

0

Eugene Mayevski 'Callback 15 年前

内存映射文件+同步对象是正确的方法(几乎与共享内存相同,但有更多的控制)。对于本地通信来说,套接字太慢了。特别是有时网络驱动程序在本地主机上比在网络上慢。

3

0

Yodan Tauber 15 年前

我们系统的几个部分已经重新设计,这样我们就不需要传递30MB左右的消息,而只需要3MB。这使我们可以选择使用BinaryFormatter进行.NET远程处理,而不是使用命名管道(IpcChannel),这会得到令人满意的结果。
我们的应急计划(以防我们需要传递30MB左右的消息)是手动通过命名管道传递protobuf序列化消息。我们认为,这也提供了令人满意的结果。