.net-2.0 - 当消息变大时，IpcChannel Remoting变慢

Question

我正在评估同一机器上驻留在上的几个 .NET 2.0 进程的各种进程间通信方法。自然，.Net Remoting是一个候选人，理论上最快的配置应该是IpcChannel(命名管道)+ BinaryFormatter。

我的基准测试确实表明，通过IpcChannel进行远程处理通常可以比TcpChannel更快，但是随着消息变大(大约30 MB)，IpcChannel的吞吐量急剧下降:

Message Size    30 MB       3 MB        300 KB      3 KBRemoting / TCP  120 MB/s    115.4 MB/s  109.5 MB/s  13.7 MB/sRemoting / IPC  55 MB/s     223.3 MB/s  218.5 MB/s  20.3 MB/s

Does anyone have any idea why, or any idea how to optimize performance of either channel? I do need to pass 30 MB BLOBs around, and would like to avoid having to deal with shared memory / memory mapped files. Also, I can't afford writing these to disk (much slower).

---

The following method was used for the benchmarks (called repeatedly, measured total time, divided total payload size by total time).

private byte[] _bytes = null;

public byte[] HelloWorld(long size)
{
 if (_bytes == null || _bytes.Length != size)
 _bytes = new byte[size];
 return _bytes;
}

Answer 1

一个比共享内存小的枪，但仍然足够强大，可以用来做这件事。执行远程过程后，让它在某个固定或临时端口号上创建Listen ing套接字，从客户端连接至该端口，然后使用NetworkStream将数据从一侧写入另一侧。

我敢肯定，它将像魅力一样起作用。

This article应该帮助您入门。

而且，即使您没有提到必须将服务器和客户端都放在单独的计算机上，您仍然拥有该功能，如果您使用共享内存，该功能将消失。