Параллельные подключения WCF и ретранслятор служебной шины Azure

У меня есть служба WCF, которая прослушивает ретранслятор служебной шины Azure, который по причинам, которые я не могу изменить, я самостоятельно размещаю в службе Windows.

После того, как служба подвергается одновременной нагрузке - обычно путем предоставления ей серии длительных запросов - мы начинаем получать следующие сообщения обратно из служебной шины Azure:

<Error>
<Code>502</Code>
<Detail>Bad Gateway.TrackingId:f0e32d08-2721-464c-a108-fe63f1efc443_G23,TimeStamp:4/23/2013 8:22:18 AM</Detail>
</Error>

Мы подозреваем, что эту проблему вызывает одновременная загрузка.

Моя служба полностью лишена гражданства.

ServiceHost = a WebServiceHost which we instantiate ourselves.
Binding = BasicHttpRelayBinding
InstanceContextMode = Single
ConcurrencyMode = Multiple
SessionMode = NotAllowed
ServiceThrottlingBehaviour.MaxConcurrentConnections = A very large number
Transport = Streaming

У меня четыре вопроса:

  1. Вышеупомянутая ошибка похожа на проблему одновременной загрузки?
  2. Какие еще варианты конфигурации мне следует рассмотреть, чтобы предложить больший масштаб.
  3. Что происходит в автономной среде Window Service, когда исчерпывается лимит одновременных подключений? Служба просто выйдет из строя? Будут ли соединения ставиться в очередь?
  4. Есть ли способ надежно отслеживать количество одновременных подключений в любой момент времени?

azure azureservicebus concurrency wcf
person Gavin Osborn    schedule 23.04.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я сотрудник Azure Service Bus Relay.

Я только что запросил вашу проблему. (Для справки в будущем было бы намного проще, если бы я знал, какое пространство имен вы используете.)

Похоже, что ServiceHost Listener не был обнаружен как подключенный к служебной шине при попытке выполнения запроса 502.

Самый простой способ отладить это - перехватить _1 _ до ваших конечных точек и подключить событие OnFaulted к ServiceHost.

Также обратите внимание, что определенные виртуальные машины в служебной шине могут отключаться на короткие периоды времени. В этом случае ваш ServiceHost может быть отключен примерно на 5–15 секунд. Лучший способ избежать этого - всегда обеспечивать размещение (2) ServiceHosts в отдельных процессах / доменах приложений, чтобы любой сбой одной виртуальной машины не повлиял на вашу службу. (Это очень похоже на рекомендации по размещению веб-сайтов.)

Если после выполнения этих рекомендаций возникнут какие-либо непредвиденные проблемы, свяжитесь со мной по адресу [email protected], и мы займемся расследованием.

person Todd Reifsteck    schedule 24.04.2013
comment
Привет, Тодд, спасибо за ответ. Мы использовали ConnectionStatusBehaviour для диагностики нашего соединения и не отслеживали никаких событий соединения в течение этого времени. В настоящее время в Австралии государственный праздник, но я приму ваше предложение и свяжусь с вами для уточнения деталей, когда вернусь на работу. Еще раз спасибо. - person Gavin Osborn; 25.04.2013