6

Я использую служебную шину с nettcprelaybinding. Одной из сторон является сервер OnPremise, который имеет постоянное подключение к служебной шине. На другом конце есть веб-роль Azure, которая отвечает на входящие веб-запросы, открывая соответствующую служебную шину и извлекая информацию с сервера.Характеристики реле Azure Servicebus

Меня беспокоит производительность создания канала. Для установления нового соединения с сервером onpremise через служебную шину требуется несколько секунд. Кэширование моего ChannelFactory, похоже, мало помогает. Эффективность передачи после открытия канала очень хорошая.

Любые предложения по улучшению производительности. Кэшировать информацию в Azure можно только в определенной степени. Мне нужно подключиться к серверу onpremise.

Могу ли я каким-то образом установить пул соединений на служебную шину?

Более того, существует множество разных серверов onpremise, поэтому это не просто одно соединение, чтобы поддерживать жизнь.

ответ

2

Вы должны уметь объединить соединения, но балансировочные балансиры Azure будут terminate any open connection that sits idle for more then 60 seconds. Поэтому, если вы кешируете соединение дольше, чем между вызовами, вам нужно будет реализовать какой-то шаблон сердечного ритма, чтобы поддерживать связь.

Другой вариант, который вы, возможно, захотите рассмотреть, - Azure Connect. Это позволяет создавать соединение ipsec point to point из облачных ресурсов на локальный сервер. Он требует, чтобы клиент был установлен в локальных ящиках, которые вы хотите подключить, но некоторые из них использовали его для установления простого соединения с шлюзом к локальной службе прокси.

+0

Спасибо за хорошую обратную связь. Не знал о 60-секундном лимите. Если я хочу объединить соединения. Какой хороший способ сделать это? Я нашел информацию об этом, выполнив вашу ссылку (http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9). Но является ли это хорошим решением в среде с несколькими экземплярами Azure? Если канал открыт на одном экземпляре, а следующий клиент выполняется в другом экземпляре? Или балансировка нагрузки гарантирует, что один и тот же экземпляр используется? – user1284390

+0

Как я понимаю, каждый экземпляр получает свое собственное соединение. И поскольку они хранят их открытыми, вам необходимо знать максимальные ограничения подключения (2000 или некоторые из таких, которые, как я полагаю), которые разрешены в одном пространстве имен. Если это хорошо или плохо для этого, это зависит от ваших потребностей в производительности и масштабируемости. – BrentDaCodeMonkey

+0

Это немного устаревшее - но только FYI, похоже, что большинство Azure LB теперь основаны на программном обеспечении и имеют тайм-аут по умолчанию 4 минуты (не 1 минута с предыдущими аппаратными LB) - и теперь это настраивается. Тем не менее, мне непонятно, на данный момент, если клиентская библиотека Service Bus автоматически использует TCP KeepAlive, и, следовательно, тайм-аут LB на самом деле не является проблемой: https://azure.microsoft.com/en-us/blog/new-configurable-idle-timeout-for-azure-load-balancer/ – Jmoney38

7

Я являюсь членом команды Service Bus в Microsoft. Стоимость открытия соединения высока по сравнению с отправкой сообщений из-за нескольких сообщений, необходимых для того, чтобы обе стороны обеспечили, чтобы они разговаривали друг с другом.

Смягчение для этого - кеширование канала, а не кэширование ChannelFactory. Для подключения NetTcpRelayBinding выполняются фоновые сигналы сохранения активности, которые должны гарантировать, что канал остается открытым.

+0

В WCF я должен обратить внимание на неисправные каналы и воссоздать прокси-сервер, если возникает исключение. В этом отношении аналогична сервисная шина? Как мне обрабатывать исключения в Service Bus с кэшированным клиентом? – LamonteCristo

+0

Еще раз спасибо за отзыв. С точки зрения веб-роли, может ли кто-нибудь указать мне на рекомендуемый способ кэширования каналов реле?Могу ли я кэшировать каналы на каждом экземпляре веб-роли или я мог бы использовать кеш Azure, который можно было бы использовать среди экземпляров? makerofthings7: Я думаю, вы можете обработать исключение, как с «нормальным» WCF, но имейте в виду, что это связано только с одним из двух соединений. Servicebus берет соединения, по одному с каждой стороны. Поэтому, если кто-то идет плохо, другой не уведомляется автоматически. – user1284390

Смежные вопросы