単一のTCPチャネルは、Azureのサービスバスで、Redisのキャッシュ、キューなど

Question

十分ではありませんない場合、私のような複数の場所、で勧告のこの種の見てきました：

複数の工場：ほかのすべてのクライアント（送信者受信者へ）は、1つのTCP接続を共有します。最大メッセージスループットは、このTCP接続を経由できる操作の数によって制限されます。 1つの工場で得られるスループットは、TCPの往復時間とメッセージサイズによって大きく異なります。高いスループット率を得るには、複数のメッセージングファクトリを使用する必要があります。

Redis、RabbitMQなどと同様の機能があります。私の質問は、どのように1つのTCPチャネルが使い尽くされるのでしょうか？私は単一のTCPチャネルに帯域幅制限がないと信じています。

なぜ、人々は高スループットのために複数のチャネルを持つことを提案するのですか？ので、それは次のとおりです。

1. は場合、クライアントアプリケーションは、単一のTCPチャネルに小さなメッセージの多くを送信し、各操作は、TCPソケット上のロックを取得して、メッセージを送信します。ロックの競合が発生する可能性があります。また、複数のtcpチャネルを使用すると、この競合はある程度解決できます。

2. 大きなメッセージがtcpチャネルで送信される場合は、シリアライズ/デシリアライズしてチャネルにプッシュするまでに時間がかかることがあります。他の小さなメッセージをブロックすることができます。

これらは実際の理由ですか（これらの前提が間違っている場合、本当の理由は何ですか）？

Answer 1

基本的には正しいです。 クライアント1 - > TCP/IP --->サーバー（何らかの処理を行う） クライアント2はサーバーに要求を送信しますか？クライアント2はクライアント1の終了を待つ必要があります（ここでのコンテキストはI/Oの遮断に関するものと仮定します）。したがって、複数のTPC接続がある場合、クライアント2はクライアント1 ==>スループットを同時に要求することができます。 しかし、よりアクティブな接続を維持するためのコストがかかります。リクエストを処理するために十分な接続があることを確認し、「アイドル」接続の数を最小限に抑える必要があります。