Когда сообщения становятся больше, IpcChannel Remoting становится медленнее

Question

Я оценивающих различные методы межпроцессного связи для нескольких .NET 2.0 процессов, проживающих на той же машине. Естественно, .NET Remoting является кандидатом, и теоретически самой быстрой конфигурацией должен быть IpcChannel (именованные каналы) + BinaryFormatter.

Мои тесты действительно показывают, что Remoting над IpcChannel может в основном быть быстрее, чем TcpChannel, но IpcChannel показывает резкое падение производительности, как сообщения становится больше (около 30 МБ):

 
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

Ружье меньше, чем разделяемой памяти, но все еще достаточно мощные для работы будет сокеты. После выполнения удаленной процедуры создайте сокет Listen на каком-либо фиксированном или специальном номере порта, подключитесь от клиента к нему, используйте NetworkStream для записи данных с одной стороны на другую.

Он будет работать как шарм, я уверен.

This article должно начаться.

И даже если вы не упоминаете ничего о необходимости иметь сервер и клиент на отдельных компьютерах, вы все равно будете иметь эту способность, которая исчезнет, ​​если вы используете общую память.

Answer 2

Почему вы хотите избежать общей памяти? Это самый очевидный выбор для перемещения больших BLOB.

Answer 3

«Странное» поведение при больших размерах сообщений (30 МБ), безусловно, связано с давлением GC. Кстати, BinaryFormatter должен быть самым медленным из всех возможных форматировщиков. DataContractFormatter может быть намного лучше или написанная вручную такая, как эта красавица http://codebetter.com/blogs/gregyoung/archive/2008/08/24/fast-serialization.aspx должна быть примерно в 16 раз быстрее. Как вы измерили время? Был ли процесс отправки и получения одним и тем же? Я думаю, что при приеме 120 МБ/с неплохо для .net с очень занятым сборщиком мусора. Вы должны посмотреть счетчик производительности% GC Time, чтобы проверить, высок ли он. Если это> 95%, вы должны использовать память более экономно. Как уже отмечают другие комментаторы, файлы с отображением памяти - это путь, если вам нужно передавать огромные объемы данных между процессами. Есть много свободных реализаций вокруг как

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

и

http://msdn.microsoft.com/en-us/library/ff650497.aspx (Smart Client Offline Application блок имеет одну DLL, который действительно содержит хорошую реализацию).

С уважением, Alois Kraus