本地 IPC 的平均性能测量
我们现在正在评估当前项目的不同 IPC（或更确切地说 RPC）方法，该项目还处于早期阶段。性能非常重要，因此我们正在进行一些测量来帮助我们做出选择。我们将进行通信的进程将驻留在同一台计算机上。
一个单独的有效选项是完全避免 IPC（通过将一个进程的功能封装在 .NET DLL 中并让另一个进程使用它），但这是我们真正希望避免的一个选项，因为这两个部分软件是由两家独立的公司开发的，我们发现维护良好的“栅栏”非常重要，这样才能成为好邻居。
我们的测试包括使用每种方法跨进程边界传递消息（包含不同大小的 BLOB）。这些是我们得到的数据（性能范围与消息大小范围相关）：
- Web 服务（基于 HTTP 的 SOAP）：
- 25-30 MB/s 当二进制数据编码为 Base64 时（默认）
- 使用 MTOM 时为 70-100 MB/s
- .NET Remoting（BinaryFormatter 超过TCP）：100-115 MB/s
- 控制组 - DLL 方法调用 + 内存复制：800-1000 MB/s
现在，我们已经到处寻找有关这些（和其他）IPC 方法的一些平均性能数据，包括原始 TCP 环回套接字的性能，但找不到任何数据。这些数字看起来正常吗？为什么这些本地IPC方法的性能比复制内存至少慢10倍？即使使用原始套接字，我也无法获得更好的结果 - TCP 的开销有那么大吗？
We are now assessing different IPC (or rather RPC) methods for our current project, which is in its very early stages. Performance is a big deal, and so we are making some measurements to aid our choice. Our processes that will be communicating will reside on the same machine.
A separate valid option is to avoid IPC altogether (by encapsulating the features of one of the processes in a .NET DLL and having the other one use it), but this is an option we would really like to avoid, as these two pieces of software are developed by two separate companies and we find it very important to maintain good "fences", which make good neighbors.
Our tests consisted of passing messages (which contain variously sized BLOBs) across process boundaries using each method. These are the figures we get (performance range correlates with message size range):
- Web Service (SOAP over HTTP):
- 25-30 MB/s when binary data is encoded as Base64 (default)
- 70-100 MB/s when MTOM is utilized
- .NET Remoting (BinaryFormatter over TCP): 100-115 MB/s
- Control group - DLL method call + mem copy: 800-1000 MB/s
Now, we've been looking all over the place for some average performance figures for these (and other) IPC methods, including performance of raw TCP loopback sockets, but couldn't find any. Do these figures look sane? Why is the performance of these local IPC methods at least 10 times slower than copying memory? I couldn't get better results even when I used raw sockets - is the overhead of TCP that big?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
共享内存是最快的。
生产者进程可以将其输出放入进程之间共享的内存中，并通知其他进程共享数据已更新。在 Linux 上，您自然会将互斥锁和条件变量放在同一共享内存中，以便其他进程可以等待条件变量的更新。
Shared memory is the fastest.
A producer process can put its output into memory shared between processes and notify other processes that the shared data has been updated. On Linux you naturally put a mutex and a condition variable in that same shared memory so that other processes can wait for updates on the condition variable.
内存映射文件+同步对象是正确的方法（几乎与共享内存相同，但具有更多控制）。套接字对于本地通信来说太慢了。特别是有时，本地主机的网络驱动程序比网络驱动程序慢。
Memory-mapped files + synchronization objects is the right way to go (almost the same as shared memory, but with more control). Sockets are way too slow for local communications. Especially it sometimes happens that network drivers are slower with localhost, than over network.
我们系统的几个部分已经过重新设计，这样我们就不必传递 30MB 的消息，而是传递 3MB 的消息。这使我们能够选择使用 BinaryFormatter 的 .NET Remoting，而不是命名管道 (IpcChannel)，这给出了令人满意的结果。
我们的应急计划（以防万一我们确实需要传递 30MB 消息）是通过命名管道手动传递 protobuf 序列化消息。我们确定这也能提供令人满意的结果。
Several parts of our system have been redesigned so that we don't have to pass 30MB messages around, but rather 3MB. This allowed us to choose .NET Remoting with BinaryFormatter over named pipes (IpcChannel), which gives satisfactory results.
Our contingency plan (in case we ever do need to pass 30MB messages around) is to pass protobuf-serialized messages over named pipes manually. We have determined that this also provides satisfactory results.