本地IPC的平均性能测量

时间:2010-11-22 14:18:08

标签: performance sockets tcp ipc rpc

我们现在正在为我们当前的项目评估不同的IPC(或更确切地说是RPC)方法,该项目处于早期阶段。性能是一个大问题,因此我们正在进行一些测量以帮助我们做出选择。我们将进行通信的流程将驻留在同一台计算机上

一个单独的有效选项是完全避免使用IPC(通过在.NET DLL中封装其中一个进程的功能并让另一个进程使用它),但这是我们真正想要避免的选项,因为这些两个软件是由两个独立的公司开发的,我们发现保持良好的“围栏”非常重要,这些“围栏”可以成为好邻居。

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

  • Web服务(SOAP over HTTP):
      二进制数据编码为Base64时的
    • 25-30 MB / s (默认)
    • 使用MTOM时
    • 70-100 MB / s
  • .NET Remoting(TCP上的BinaryFormatter): 100-115 MB / s
  • 控制组 - DLL方法调用+内存副本: 800-1000 MB / s

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

3 个答案:

答案 0 :(得分:3)

共享内存最快。

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

答案 1 :(得分:0)

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

答案 2 :(得分:0)

  • 我们系统的几个部分已经过重新设计,因此我们不必传递30MB的消息,而是3MB。这使得我们可以选择使用BinaryFormatter进行.NET Remoting而不是命名管道(IpcChannel),这会产生令人满意的结果。

  • 我们的应急计划(如果我们需要传递30MB消息)是手动通过命名管道传递protobuf序列化消息。我们已经确定这也会提供令人满意的结果。