Параллельный доступ к клиентскому прокси WCF

Question

Я сейчас немного поиграюсь с WCF, во время этого я задал вопрос, где я не уверен, что я на правильном пути.

Давайте предположим простую настройку, которая выглядит следующим образом: client -> service1 -> service2. Связь основана на tcp.

Так что я не уверен, если есть смысл, что service1 кэширует клиентский прокси для service2. Поэтому я могу получить многопоточный доступ к этому прокси, и мне придется с этим справиться.

Я бы хотел воспользоваться сеансом tcp, чтобы получить лучшую производительность, но я не уверен, поддерживается ли эта "архитектура" WCF / network / чем-либо еще. Проблема, которую я вижу, заключается в том, что все общение происходит по одному и тому же каналу, если я не использую блокировки или другую синхронизацию.

Полагаю, лучшая идея - кэшировать прокси в переменную threadstatic. Но прежде чем я это сделаю, я хотел подтвердить, что не очень хорошая идея иметь только один экземпляр прокси.

ТИА Martin

Answer 1

Да, эта архитектура поддерживается WCF. Каждый день я работаю с приложениями, которые используют похожие структуры, используя NetTCPBinding.

Самая большая проблема, о которой стоит беспокоиться, - это ConcurrencyMode различных задействованных сервисов, и убедитесь, что они не блокируются без необходимости. Очень легко попасть в сценарий, в котором вам будут гарантированы тайм-ауты или, по крайней мере, вы будете иметь низкую производительность из-за нескольких синхронных вызовов через границы служб. Даже вызовы OneWay не гарантируют немедленный возврат.

Answer 2

Я уже использую такую ​​структуру. У меня есть один сервис, который сотрудничает с некоторыми другими сервисами и реализует реализацию. Конечно, в моем случае клиент вызывает какой-то односторонний метод первой услуги. Я получаю очень хорошую выгоду. Конечно, я также настроил его так, чтобы ограничить количество одновременных вызовов в некоторых случаях.

Answer 3

Если вы не знаете, что у вас проблемы с производительностью, зачем беспокоиться о кешировании? Вы открываете себя риску неправильной реализации многопоточного кода без какой-либо явной, ощутимой выгоды.

Вы уже измерили производительность или профилировали приложение, чтобы увидеть, на что оно тратит свое время? Если нет, тогда, когда вы это сделаете, вы вполне можете обнаружить, что издержки нескольких сеансов TCP не связаны с проблемами производительности. Вы можете пожелать, чтобы у вас было время оптимизировать какую-то другую часть вашего приложения, но вы потратили это время на оптимизацию чего-то, что не нужно было оптимизировать.

Answer 4

Во-первых, убедитесь, что вы знаете о поведении ThreadStatic в приложениях ASP.NET:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

Тот же поток, который начал ваш запрос, может не совпадать с тем, который его завершает. По сути, единственный безопасный способ хранения локального хранилища Thread в приложениях ASP.NET - внутри HttpContext. Следующим очевидным подходом будет создание клиента-оболочки для управления прокси-сервером клиента WCF и обеспечения безопасности каждого запроса ввода-вывода с использованием блокировок.

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

Answer 5

осторожно с threadstatic, .net изменяет поток, так что переменная может получить значение NULL.

Для сеанса ... возможно, вы могли бы использовать вызовы с включенным сеансом: http://msdn.microsoft.com/en-us/library/ms733040.aspx

Но я бы не рекомендовал использовать, если у вас нет проблем с производительностью. Я бы использовал обычный способ, или если служба 1 предназначена только для пересылки, вы могли бы легко использовать эту функцию с 4.0: http://www.sdn.nl/SDN/Artikelen/tabid/58/view/View/ArticleID/2979/Whats-New-in-WCF-40.aspx

Привет