当消息变大时，IpcChannel Remoting会变慢

Question

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

我的基准测试确实表明，通过IpcChannel进行远程处理可能比TcpChannel更快，但是随着消息变大（大约30 MB），IpcChannel显示吞吐量急剧下降：

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

有没有人知道为什么或任何想法如何优化任一频道的表现？我确实需要传递30 MB的BLOB，并且希望避免必须处理共享内存/内存映射文件。另外，我不能把这些写入磁盘（慢得多）。

---

以下方法用于基准测试（重复调用，测量的总时间，按总时间划分的总有效负载大小）。

private byte[] _bytes = null;

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

Answer 1

为什么要避免共享内存？这是移动大型BLOB最明显的选择。

Answer 2

大邮件大小（30MB）的“奇怪”行为确实可以从GC压力中获得。顺便说一下，BinaryFormatter应该是所有可能的格式化程序中最慢的。 DataContractFormatter可能会好得多，或者手写的像这样的美http://codebetter.com/blogs/gregyoung/archive/2008/08/24/fast-serialization.aspx应该快16倍。你是如何衡量时代的？发送和接收过程是否相同？我认为120 MB / s发送接收对.net非常有用，非常繁忙的垃圾收集器。您应该查看％GC时间性能计数器以检查它是否很高。如果是> 95％你应该谨慎使用记忆。 正如其他评论者已经指出的那样，如果您需要在进程之间传递大量数据，那么内存映射文件就是您的选择。有许多免费的实现，如

  

http://www.codeproject.com/KB/recipes/MemoryMappedGenericArray.aspx

和

  

http://msdn.microsoft.com/en-us/library/ff650497.aspx   （智能客户端离线应用程序   块有一个dll确实包含一个   很好的实现）。

此致，   Alois Kraus

Answer 3

一个小于共享内存的枪，但仍然足够强大的工作将是插座。在执行远程过程时，让它在某个固定或临时端口号上创建Listen套接字，从客户端连接到它，使用NetworkStream将数据从一端写入另一端。 / p>

我确定它会像魅力一样起作用。

This article应该让你开始。

而且，即使你没有提到任何关于必须让服务器和客户端连接到不同的机器上的任何东西，你仍然会有这种能力，如果你使用共享内存，它将会消失。