test

Sun Java System Message Queue 3.7 UR1 管理ガイド

パフォーマンスに影響するメッセージサービスの要因

メッセージングアプリケーションのパフォーマンスは、アプリケーション設計だけでなく、メッセージのルーティングと配信を実行するメッセージサービスによっても影響を受けます。

次の節では、パフォーマンスに影響することのあるさまざまなメッセージサービスの要因について説明します。これらの要因の影響を理解しておくことは、メッセージサービスの内容を変更したり、配置済みのアプリケーションで発生することのあるパフォーマンスボトルネックを診断し解決したりする上で重要となります。

Message Queue サービスのパフォーマンスに影響するもっとも重要な要因は、次のとおりです。

以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。

ハードウェア

Message Queue ブローカとクライアントアプリケーションのどちらの場合も、CPU の処理速度と使用可能なメモリーはメッセージサービスのパフォーマンスを決定する主要な要因となります。処理性能を強化して、多数のソフトウェア制限をなくす一方で、メモリーを追加して処理速度と能力を増加させることができます。ただし、一般に、単にハードウェアをアップグレードするだけでボトルネックを解消すると多額の費用がかかります。

オペレーティングシステム

同じハードウェアプラットフォームを前提とした場合でも、異なるオペレーティングシステムの効率によって、パフォーマンスも変わってきます。たとえば、オペレーティングシステムが採用しているスレッドモデルが、ブローカがサポート可能な同時接続数に大きく影響することがあります。一般に、すべてのハードウェアが同じであれば、Solaris は通常 Linux より高速で、Linux は Windows より高速です。

Java 仮想マシン (JVM)

ブローカは、ホスト JVM 内で実行され、ホスト JVM によってサポートされる Java プロセスです。そのため、JVM 処理は、ブローカがメッセージをいかに早く効率良くルーティングし配信できるかを決定する重要な要因となります。

特に、JVM のメモリーリソースの管理が不可欠となる場合があります。増加し続けるメモリーの負荷に対応するには、JVM に十分なメモリーを割り当てる必要があります。さらに、JVM は定期的に未使用のメモリーを再利用します。このメモリー再利用がメッセージの処理を遅らせることがあります。JVM のメモリーヒープが大きくなるほど、メモリー再利用時に経験することのある、潜在する遅延も長くなります。

接続

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

ブローカの接続の制限

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

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

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

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

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

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

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

図は、さまざまなトランスポートプロトコルの相対速度を示します。結果は文字で説明されます。

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

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

メッセージサービスのアーキテクチャー

Message Queue メッセージサービスは、シングルブローカ、または複数の連結されたブローカインスタンスで構成されたクラスタとして実装できます。

ブローカに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカは最終的に、ファイル記述子、スレッド、メモリーの制限などのリソースの限界を超えてしまいます。増え続ける負荷に対処するための 1 つの方法は、Message Queue メッセージサービスにブローカインスタンスを追加して、クライアントの接続とメッセージのルーティングおよび配信を複数のブローカに分散することです。

一般に、ブローカインスタンスの追加は、クライアント、特にメッセージプロデューシングクライアントがクラスタ間で均等に分散されている場合に最適に動作します。クラスタ内のブローカ間でのメッセージ配信にはオーバーヘッドが伴うため、接続数とメッセージ配信レートが制限されているクラスタでは、シングルブローカよりパフォーマンスが低くなります。

また、ブローカクラスタを使用してネットワークの帯域幅を最適化することもできます。たとえば、クラスタ内の一連のリモートブローカ間で、速度の遅い、長距離のネットワークリンクを使用する一方で、個々のブローカインスタンスへのクライアントの接続に、高速なリンクを使用することができます。

クラスタの詳細については、第 9 章「ブローカクラスタを使用した作業」を参照してください。

ブローカの制限と動作

メッセージを処理するためにブローカに要求されるメッセージスループットは、ブローカがサポートするメッセージングアプリケーションの使用パターンによって異なります。ただし、ブローカでは、メモリーや CPU サイクルなどのリソースに制限があります。リソースの制限により、ブローカは、過負荷となり、無応答または不安定となるポイントに達してしまうことがあります。

Message Queue メッセージブローカには、メモリーリソースを管理し、ブローカのメモリー不足を防ぐためのメカニズムが組み込まれています。これらのメカニズムに含まれるのは、ブローカまたは個々の物理的送信先が保持できるメッセージ数またはメッセージのバイト数についての設定可能な制限と、物理的送信先の制限に達したときに起動できる一連の動作です。

これらの設定可能なメカニズムを使用して、システムが過負荷にならないように、メッセージの受信と送信のバランスを取ることができますが、これには注意深い監視と調整が必要です。これらのメカニズムは、オーバーヘッドを増加させ、メッセージのスループットを制限することがありますが、それでも動作の完全性を維持します。

データストアのパフォーマンス

Message Queue は、ファイルベースの持続モジュールと JDBC ベースの持続モジュールの両方をサポートしています。ファイルベースの持続モジュールでは、持続データを格納するために個別のファイルを使用します。JDBC ベースの持続では、JDBC™ (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアを必要とします。一般的に、ファイルベースの持続は、JDBC ベースの持続よりも高速です。ただし、JDBC 互換のストアによって提供される冗長性や管理機能を好むユーザーもいます。

ファイルベースの持続の場合は、持続的な操作によりメモリー内の状態とデータストアとを同期化するように指定することで、信頼性を高められます。この同期化は、システム破壊によるデータの損失をなくす上で役立ちますが、パフォーマンスが犠牲になります。

クライアントランタイムの設定

Message Queue クライアントランタイムは、クライアントアプリケーションに Message Queue メッセージサービスへのインタフェースを提供します。クライアントランタイムでは、物理的送信先にメッセージを送信し、物理的送信先からメッセージを受信する場合に、クライアントに必要なすべての処理をサポートします。クライアントランタイムは、接続ファクトリ属性値を使って設定可能で、パフォーマンスとメッセージスループットを向上させるように、接続フロー測定、コンシューマフローの制限、接続フロー制御などのプロパティーと動作を設定できます。これらの機能とそれを設定するために使用される属性の詳細は、「クライアントランタイムのメッセージフローの調整」を参照してください。