Когда сообщения становятся больше, IpcChannel Remoting становится медленнее - PullRequest
9 голосов
/ 02 декабря 2010

Я оцениваю различные методы межпроцессного взаимодействия для пары .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 МБ больших двоичных объектов, и я хотел бы избежать необходимости иметь дело с файлами общей памяти / карты памяти.Кроме того, я не могу позволить себе записать их на диск (намного медленнее).


Следующий метод использовался для эталонных тестов (вызывается повторно, измеряется общее время, делится общее полезная нагрузка размер по общему времени).

private byte[] _bytes = null;

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

Ответы [ 3 ]

1 голос
/ 13 декабря 2010

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

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

и

http://msdn.microsoft.com/en-us/library/ff650497.aspx (Smart Client автономное приложение Блок имеет одну DLL, которая содержит хорошая реализация).

* * 1017 С уважением, Алоис Краус
1 голос
/ 19 декабря 2010

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

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

Эта статья должна помочь вам начать.

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

1 голос
/ 12 декабря 2010

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

...