接続

クライアントとブローカ間の接続の数と速度は、メッセージサービスが処理可能なメッセージ数とメッセージ配信速度に影響することがあります。

ブローカの接続の制限

ブローカへのアクセスはすべて、接続経由で行われます。同時接続数の制限によって、ブローカを同時に使用できるプロデューシングクライアントまたはコンシューミングクライアントの数が左右されることがあります。

ブローカへの接続の数は、一般に、使用可能なスレッド数によって制限されます。Message Queue は、専用スレッドモデルまたは共有スレッドモデルのどちらかをサポートするように設定できます (「スレッドプール管理」を参照)。

専用スレッドモデルは、各接続が専用のスレッドを持つため非常に高速ですが、接続の数は使用可能なスレッド数によって制限されます。この場合、接続ごとに、入力スレッドと出力スレッドが 1 つずつ必要です。共有スレッドモデルには、接続数の制限はありませんが、多数の接続でスレッドを共有するため、オーバーヘッドが増え、スループットが悪化します。これは、多くの接続が使用中のとき特に顕著になります。

トランスポートプロトコル

Message Queue ソフトウェアを使うと、クライアントは各種の低レベルのトランスポートプロトコルを使用してブローカと通信できます。Message Queue は、「接続サービス」で説明されている接続サービスとそれに対応するプロトコルをサポートします。

暗号化、ファイアウォールを介したアクセスなどのプロトコルは、アプリケーション要件に基づいて選択されますが、選択結果はパフォーマンス全体に影響を及ぼします。

図 11–2 トランスポートプロトコルの速度

テストでは、2 つのケースでの TCP と SSL のスループットを比較しました。2 つのケースとは、1K バイトの持続メッセージを、永続サブスクリプションとAUTO_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信する高信頼性シナリオと、1K バイトの持続性のないメッセージを、永続サブスクリプションと DUPS_OK_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信するハイパフォーマンスシナリオです。

通常、高信頼性ケースの方がプロトコルによる影響は少ないことが分かりました。これは、高信頼性のケースで必要な持続メッセージのためのオーバーヘッドの方が、プロトコルの速度より、スループットを制限する重要な要因となるからです。そのほかの特性は次のとおりです。

• TCP は、ブローカと通信する最速の方法を提供します。

• SSL は、メッセージの送信と受信に関しては、TCP より 50 〜 70% 低速です。持続メッセージの場合は 50%、持続性のないメッセージの場合は約 70% です。さらに、初期接続の確立は、SSL を使用した場合の方が低速で数秒かかります。これは、クライアントとブローカ、または HTTPS の場合は Web Server で、送信するデータの暗号化に使う非公開鍵の作成が必要なためです。低レベルの各 TCP パケットの暗号化と復号化に必要な追加処理によって、パフォーマンスの低下が引き起こされます。

• HTTP は、TCP または SSL より低速です。HTTP ではクライアントとブローカ間のプロキシとして、Web サーバー上で実行しているサーブレットを使用します。パケットを HTTP 要求へカプセル化する必要がある点と、メッセージがブローカへ到達するには、クライアントからサーブレットへ、サーブレットからブローカへという 2 つの段階が必要である点から、パフォーマンスへのオーバーヘッドが発生します。

• HTTPS は HTTP より低速です。これは、クライアントとサーブレット間、およびサーブレットとブローカ間でパケットを暗号化するためにオーバーヘッドが必須となるからです。