nettcprelaybinding でサービス バスを使用しています。一方は、サービス バスに常時接続しているオンプレミス サーバーです。もう一方の端には、適切なサービス バスを開き、サーバーから情報を取得することで、着信 Web 要求に応答する Azure Web ロールがあります。
私の懸念は、チャネル作成のパフォーマンスです。サービス バスを介してオンプレミス サーバーへの新しい接続を確立するには、数秒かかります。私のChannelFactoryをキャッシュしてもあまり役に立たないようです。チャネルが開いた後の転送パフォーマンスは非常に優れています。
パフォーマンスを改善する方法に関する提案。Azure での情報のキャッシュは、ある程度しか実行できません。オンプレミス サーバーに接続する必要があります。
どうにかしてサービス バスへの接続プールを確立できますか?
さらに、多数の異なるオンプレミス サーバーが存在するため、1 つの接続だけを維持する必要はありません。
私はマイクロソフトの Service Bus チームのメンバーです。接続を開くコストは、メッセージを送信する場合と比較して高くなります。これは、双方が確実に通信できるようにするために複数の通信が必要になるためです。
これを軽減するには、ChannelFactory をキャッシュするのではなく、チャネルをキャッシュします。チャネルが開いたままになるように、NetTcpRelayBinding 接続に対して実行されるバックグラウンド キープアライブ ping があります。
接続をプールできるはずですが、Azure ロード バランサーは、60 秒以上アイドル状態になっている開いている接続を終了します。そのため、呼び出し間よりも長く接続をキャッシュしている場合は、接続を維持するために何らかのハートビート パターンを実装する必要があります。
考慮すべきもう 1 つのオプションは、Azure Connect です。これにより、クラウドでホストされているリソースからオンプレミス サーバーへの ipsec ポイント ツー ポイント接続を作成できます。接続するオンプレミスのボックスにもクライアントをインストールする必要がありますが、オンプレミスのプロキシ サービスへの単純なゲートウェイ接続を確立するためにクライアントを使用している人もいます。