Я не уверен, что стандартный подход .Net будет таким, как вы хотите ...
Каждая упомянутая вами технология .Net связана с измеримыми затратами на установку и демонтаж, и WCF является одним из худших из них. Если ваша цель - производительность, вам нужно напрямую общаться с портами, а не использовать стандартную оболочку для их обработки. Я бы даже сказал, что если производительность действительно является ключевым фактором, вам нужно смотреть на прямую функцию C вместо языка .Net. (Некоторые, конечно, со мной не согласятся, но я обнаружил, что динамические языки, такие как Ruby и Python, тоже довольно быстрые)
Другой вопрос, который вступит в игру, это ваш бэкэнд данных. Если все это находится в памяти, то запуск нескольких серверов означает, что вам придется использовать какой-то механизм кэширования, такой как memcached, чтобы синхронизировать все ваши данные. Если вы собираетесь использовать базу данных, я бы предложил использовать несколько портов, один из которых подключен к вашей базе данных, а другой - только на основе памяти. Преимущество, которое вы получаете, заключается в том, что данные, для которых не требуются базы данных, могут работать в пространстве памяти, которое работает так же быстро, как и компьютер, и процессу не нужно ждать дорогостоящих соединений с базами данных.
WCF / .Net Remoting / COM + / и т. Д. Отлично подходят для бизнес-приложений, где оборот за 1 секунду не убьет вас, но в среде реального времени, где каждая миллисекунда имеет значение, вам необходимо иметь возможность управлять весь коммуникационный стек с момента получения первого пакета до закрытия соединения. Каждый коммуникационный стек .Net, который я использовал в средах реального времени, добавлял почти 100 мс к каждому запросу. Вырезав посредника и работая напрямую с клиентом (т. Е. Читая поток прямо из порта и затем отправляя поток прямо в порт), я сократил эту стоимость и вернул время назад. Когда вы обрабатываете десятки тысяч запросов в минуту, это время становится очень важным.