Проектирование WCF-сервера с низкой задержкой

Question

Как добиться низкой задержки сервера WCF в сценарии публикации-подписки?В частности, клиенты подписываются на данные и получают обновления, о задержке идет речь между изменением данных и получением клиентом изменений?Требования к процессору, памяти, пропускной способности не важны и могут быть высокими.

Основы очевидны:двоичная сериализация, именованные каналы и т.д.Но имеет ли смысл, например, отправлять данные через всегда подключенный поток?Или отправить пакет обновлений в виде одного сообщения, чтобы уменьшить накладные расходы на RPC / заголовок?

Может быть, есть какие-то проекты с кодом или интерфейсами, доступными для использования в качестве примера?

Answer 1

Не всеобъемлющее решение, но:Чтобы уменьшить задержку, связанную с размером данных и скоростью передачи по сети, вы могли бы использовать буферы протокола Google чтобы сжать ваши данные по проводам.Проекты GitHub - это здесь.

Answer 2

Если вы используете дуплексный канал, вы можете заставить клиентов подключаться к серверу и при этом передавать другой контракт на обслуживание в качестве обратного вызова.Затем сервер использует этот обратный вызов для отправки обновлений клиенту по мере того, как они становятся доступными.

Я написал собственный механизм pub-sub, используя этот подход, и задержка примерно настолько низкая, насколько вы могли бы ожидать с помощью WCF.

Какова ваша целевая производительность?

Эта статья MSDN обсуждается использование дуплексного канала WCF.

Answer 3

Вы смотрели на

http://geekswithblogs.net/BVeldhoen/archive/2008/01/26/wcf-latency-test-harness.aspx

Он учитывает различные привязки и размеры данных.