本地IPC的平均性能测量

Question

我们现在正在为我们当前的项目评估不同的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的开销是否很大？

Answer 1

共享内存最快。

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

Answer 2

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

Answer 3

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

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