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

Question

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

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

Итак, где я не уверен, если имеет смысл, что служба1 кэширует клиентский прокси для service2. Поэтому я могу получить многопоточный доступ к этому прокси, и мне приходится иметь дело с ним.

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

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

ТИА Martin

Answer 1

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

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

Answer 2

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

Для сессии ... возможно, вы могли бы использовать сессии включены вызовы: 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

С уважением

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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