私はnettcprelaybindingでサービスバスを使用しています。一方は、サービスバスと常時接続しているOnPremiseサーバーです。もう一方の端には、適切なサービスバスを開いてサーバーから情報を取得することによって、着信するWeb要求に応答するAzure Webロールがあります。Azureサービスバス中継のパフォーマンス
私の懸案事項は、チャンネル作成のパフォーマンスです。サービスバスを介してオンプリムサーバに新しい接続を確立するまでには数秒かかります。私のChannelFactoryのキャッシュはあまり役に立たないようです。チャンネルが開いた後の転送パフォーマンスは非常に良いです。
パフォーマンスを向上させる方法に関するご提案です。 Azureでの情報のキャッシュは、ある程度しか行えません。私はonpremiseサーバーに接続する必要があります。
サービスバスへの接続プールをどうにか設定できますか？
多くの場合、さまざまなオンプリムサーバが存在するため、生き続けるための接続は1つではありません。
接続をプールできるはずですが、Azureロードバランサはterminate any open connection that sits idle for more then 60 secondsになります。コールよりも長い接続をキャッシュする場合は、接続を維持するために何らかの種類のハートビートパターンを実装する必要があります。
別のオプションとして、Azure Connectが考えられます。これにより、クラウドホステッドリソースからオンプレミスサーバーへのipsecポイントツーポイント接続を作成できます。接続するオンプレミスボックスにクライアントをインストールする必要がありますが、それを使用してオンプレミスプロキシサービスへの単純なゲートウェイ接続を確立しています。
私はマイクロソフトのサービスバスチームのメンバーです。接続を開くコストは、メッセージの送信に比べて、両者が互いに話していることを確実にするために必要な複数の通信のために高くなります。
このための緩和策は、ChannelFactoryをキャッシュするのではなく、チャネルをキャッシュすることです。 NetTcpRelayBinding接続にバックグラウンドのキープアライブpingが実行されているため、チャネルが開いたままになっている必要があります。
WCFでは、障害が発生したチャネルに注意を払う必要があり、例外が発生した場合はプロキシを再作成する必要があります。この点でサービスバスは類似していますか？キャッシュされたクライアントでサービスバス内で例外を処理する方法はありますか？ – LamonteCristo
フィードバックをお寄せいただきありがとうございます。 Webの役割の観点から、誰でも私にリレーチャネルをキャッシュする推奨方法を教えてもらえますか？各Webロールインスタンスにチャネルをキャッシュするか、インスタンス間で使用できるAzureキャッシュを使用できますか？ makerofthings7：「通常の」WCFのように例外を処理できますが、これは2つの接続のうちの1つに関連していることに留意してください。 Servicebusはそれぞれの側から1つの接続に接続します。だから1つが悪くなると、他の私の知識に自動的に通知されません。 – user1284390
フィードバックに感謝します。 60秒の制限について知らなかった。私は接続をプールしたい場合。それを行う良い方法は何ですか？私はあなたのリンク（http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9）に従うことでそれに関するいくつかの情報を見つけました。しかし、これはマルチインスタンスのAzure環境の良い解決策ですか？あるインスタンスでチャネルが開いていて、次のクライアントが別のインスタンスで実行されている場合は、または、ロードバランサは同じインスタンスが使用されていることを確認しますか？ – user1284390
私はそれを理解するので、各インスタンスは独自の接続を取得します。彼らはそれらを開いたままにしているので、単一のネームスペースで許可されている最大接続制限（2000など）を認識する必要があります。これを行うのが良いか悪いかは、パフォーマンスとスケーラビリティのニーズによって異なります。 – BrentDaCodeMonkey
これはちょっと古いですが、ほとんどのAzure LBはソフトウェアベースで、デフォルトのタイムアウト時間は4分です（従来のハードウェアベースのLBでは1分ではありません）。しかし、現在のところ、Service Busクライアントライブラリが自動的にTCP KeepAliveを実装しているので、LBタイムアウトは実際問題ではありません：https://azure.microsoft.com/en-us/blog/new-configurable-idle-time-for-azure-load-balancer/ – Jmoney38