Вопрос

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

Но они не вызываются одновременно.

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

Я нашел эту статью в MSDN, в которой говорится: <цитата>

Хотя каналы и клиенты, созданные каналы потокобезопасны, они может не поддерживать написание больше, чем одно сообщение на провод одновременно. Если вы отправляете большие сообщения, особенно при потоковой передаче, отправка операция может заблокировать ожидание еще одна отправка для завершения.

Во-первых, я не отправляю большие сообщения (только много мелких, поскольку я выполняю нагрузочное тестирование), но все же наблюдаю блокирующее поведение. Во-вторых, это довольно открытая и бесполезная документация. В нем говорится, что они «могут не поддерживать» написание более одного сообщения, но не объясняются сценарии, при которых они будут поддерживать одновременные сообщения.

Кто-нибудь может пролить свет на это?

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

Это было полезно?

Решение

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

Другие советы

Вы можете кэшировать прокси WCF, но при этом создавать канал для каждого вызова службы - это обеспечит параллелизм, не очень дорого по сравнению с созданием канала с нуля, и повторная аутентификация для каждого вызова не потребуется.Это объясняется в блоге Венлуна Донга - " Повышение производительности для создания прокси-сервера WCF в .NET 3.5 и передовых методах " (гораздо лучший источник информации и рекомендаций по WCF, чем MSDN).

Для полноты: вот запись в блоге, объясняющая наблюдаемое поведение сериализации запросов, когда канал не открывается явно:

http://blogs.msdn.com/b/wenlong/archive/2007/10/26/best-practice-always-open-wcf-client-proxy-explicitly-when-it-is-shared.aspx

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top