我正在使用帶有nettcprelaybinding的服務總線。一方是OnPremise服務器，它與服務總線有恆定的連接。另一方面，Azure Web角色通過打開相應的服務總線並從服務器獲取信息來響應傳入的Web請求。Azure Servicebus繼電器性能
我擔心的是渠道創作的表現。通過服務總線建立到服務器的新連接需要幾秒鐘的時間。緩存我的ChannelFactory似乎沒有多大幫助。頻道開放後的轉播表現非常好。
關於如何提高性能的任何建議。在Azure中緩存信息只能在一定程度上完成。我需要連接到onpremise服務器。
我可以以某種方式建立到服務總線的連接池嗎？
關於更多的事情，有許多不同的onpremise服務器，所以它不只是一個連接來保持活力。
您應該可以將連接池，但Azure負載平衡器將terminate any open connection that sits idle for more then 60 seconds。因此，如果您將連接緩存的時間比調用之間的連接時間要長，則需要實施某種心跳模式以幫助保持連接的活躍狀態。
另一個可能需要考慮的選項是Azure Connect。這使您可以創建從雲託管資源到本地服務器的IPsec點到點連接。它確實需要將客戶端安裝在您想要連接的本地箱上，但有些客戶一直使用它來建立到本地代理服務的簡單網關連接。
我是微軟Service Bus團隊的成員。與發送消息相比，打開連接的成本很高，因爲需要多方通信才能確保雙方互相通話。
對此的緩解是緩存頻道而不是緩存ChannelFactory。有NetTcpRelayBinding連接執行的後臺保持活動ping應確保通道保持打開狀態。
在WCF中，我必須注意故障通道，並在發生異常時重新創建代理。服務總線在這方面是否類似？我應該如何處理緩存客戶端的Service Bus中的異常？ – LamonteCristo 2012-04-05 16:45:24
再次感謝您的所有反饋。從網站角色的角度來看，任何人都可以指引我推薦緩存中繼頻道的方式嗎？我會在每個Web角色實例上緩存通道，還是可以使用可以在實例中使用的Azure緩存？ makerofthings7：我想你可以像處理「正常」的WCF一樣處理異常，但請記住，這隻與兩個連接中的一個有關。 Servicebus需要連接，每邊一個。所以如果一個壞了，另一個不會自動通知我的知識。 – user1284390 2012-04-06 15:35:42
感謝您的好評。不知道60秒的限制。如果我想集中連接。什麼是這樣做的好方法？我通過以下鏈接找到了一些信息（http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9）。但是，這是多實例Azure環境中的優秀解決方案嗎？如果一個通道在一個實例上打開並且下一個客戶端在另一個實例上執行？還是負載平衡器確保使用相同的實例？ – user1284390 2012-04-03 16:53:38
據我瞭解，每個實例都有自己的連接。而且，由於它們保持打開狀態，因此您需要了解單個命名空間允許的最大連接限制（2000或某些我認爲的限制）。如果它的好壞取決於你對性能和可擴展性的需求。 – BrentDaCodeMonkey 2012-04-03 18:09:15
這有點舊 - 但僅供參考，似乎大多數Azure LB現在都是基於軟件的，並且默認超時時間爲4分鐘（而現有的基於硬件的LB不超過1分鐘） - 現在可以配置。但是，目前還不清楚Service Bus客戶端庫是否自動爲您實現TCP KeepAlive，因此LB超時並不是真正的問題：https：//azure.microsoft.com/en-us/blog/new-configurable-idle-timeout-for-azure-load-balancer/ – Jmoney38 2018-01-09 03:28:09