test

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

パフォーマンス関連

この節では、パフォーマンス調整の背景について説明します。

パフォーマンス調整プロセス

メッセージングアプリケーションのパフォーマンスは、アプリケーションと Message Queue サービスの相互関係に左右されます。そのため、パフォーマンスを最大化するには、アプリケーション開発者と管理者が協力し合う必要があります。

パフォーマンスを最適化するプロセスは、アプリケーションの設計から始まります。アプリケーションが配備されたあとも、継続してメッセージサービスの調整を行います。パフォーマンス調整プロセスには、次の段階があります。

通常は、上記に概略したプロセスを繰り返し実行します。アプリケーションの配備時に、Message Queue 管理者は、メッセージサービスの適合性を評価し、アプリケーションの全般的なパフォーマンス要件を満たしているかどうかを判断します。ベンチマークテストがこれらの要件を満たす場合は、この章で説明するとおり、管理者はシステムの調整段階に入ることができます。一方、ベンチマークテストがパフォーマンス要件を満たしていない場合は、アプリケーションの再設計や配備アーキテクチャーの変更が必要となる場合があります。

パフォーマンスのさまざまな側面

一般に、パフォーマンスの基準は、メッセージサービスがプロデューサからコンシューマへメッセージを配信するときの速度と効率です。ただし、パフォーマンスには、ニーズに応じて重要度が変わるさまざまな側面があります。

接続の負荷:

メッセージプロデューサまたはメッセージコンシューマの数、もしくは、システムがサポート可能な同時接続の数です。

メッセージのスループット:

メッセージングシステムが 1 秒間に扱えるメッセージ数、またはメッセージのバイト数です。

遅延:

特定のメッセージがメッセージプロデューサからメッセージコンシューマへ配信されるまでに要する時間です。

安定性:

メッセージサービス全体の可用性、つまり過負荷や障害による影響をどれだけ抑えられるかです。

効率:

メッセージ配信の効率。使用するコンピュータリソースに関係する、メッセージスループットの評価です。

パフォーマンスのこれらの異なる評価基準は、一般に相互に関連しています。メッセージスループットが高い場合、メッセージがブローカへバックログされることは、ほとんどありません。その結果、遅延も短くなり、シングルメッセージはすぐに配信されます。ただし、遅延はさまざまな要因に左右されます。そのような要因の例としては、通信リンクの速度、ブローカの処理速度、クライアントの処理速度などがあります。

どのような場合でも、パフォーマンスには複数の異なる側面があります。一般に、その中でどれがもっとも重要となるかは、特定のアプリケーションの要件によって決まります。

ベンチマーク

ベンチマークとは、使用中のメッセージングアプリケーション用のテスト群を作成し、このテスト群を用いてメッセージスループットや、そのほかの観点からパフォーマンスを評価するプロセスです。

たとえば、複数のプロデューシングクライアントを対象に、複数の、接続、セッション、メッセージプロデューサを使用し、標準サイズの持続メッセージまたは持続性のないメッセージを一部のキューやトピック (すべてメッセージングアプリケーションの設計に依存) へ一定レートで送信するテスト群を作成できます。同様に、特定の通知モードでテスト群の物理的送信先においてメッセージを消費する複数の接続、セッション、および特定タイプのメッセージコンシューマを使用し、複数のコンシューミングクライアントをテスト群に含められます。

標準のテスト群を使用することで、メッセージが生成されてから消費されるまでに要する時間やメッセージの平均スループットレートを測定したり、システムを監視して、接続スレッド使用率、メッセージストレージデータ、メッセージフローデータ、そのほかの関連するメトリックスを監視したりできます。その後、パフォーマンスに悪影響が出る上限まで、メッセージの生成レート、メッセージプロデューサの数、その他の変数を増加させることができます。実現可能な最大スループットが、メッセージサービス設定のベンチマークになります。

このベンチマークを基に、テスト群の特性の一部を変更できます。パフォーマンスに影響しそうな要因すべてを慎重に制御すれば (「パフォーマンスに影響するアプリケーション設計の要因」を参照)、これらの要因の変化によるベンチマークへの影響を理解できます。たとえば、接続数またはメッセージ数を 5 倍もしくは 10 倍に増やし、パフォーマンスに与える影響を調べることができます。

逆に、アプリケーションベースの要因を一定に保ち、たとえば、接続プロパティー、スレッドプールプロパティー、JVM メモリー制限、制限の動作、ファイルベースの持続と JDBC ベースの持続などを変更するといった、制御方法でブローカ設定を変更して、これらの変更がパフォーマンスに及ぼす影響を判断することもできます。

アプリケーションのこのようなベンチマークから、メッセージサービスを調整して配置済みのアプリケーションのパフォーマンスを向上させたいときに有用な情報を得られます。ベンチマークによって、1 か所の変更や一連の変更による影響を正確に予測できます。

原則として、ベンチマークは、管理されたテスト環境で、メッセージサービスを安定させるため長期間実施する必要があります。Java コードをマシンコードに変換する JIT コンパイルによる起動時には、パフォーマンスに悪影響が及びます。

基準になる使用パターン

メッセージングアプリケーションが配置され稼働されたあとは、基準になる使用パターンを確立することが重要となります。要求のピークがいつ発生するか把握し、その要求の定量化を図ります。たとえば、通常、要求はエンドユーザー数、アクティビティーレベル、時間帯、またはこれらすべてによって左右されます。

基準になる使用パターンを確立するには、メッセージサービスを一定期間監視して、次のようなデータを調べる必要があります。

また、メトリックスデータにより提供される平均値とピーク値を使用することもできます。

これらの基準になるメトリックスを設計時の期待値と比較することが重要です。それによって、クライアントコードが正常に動作していることを確認します。たとえば、接続が開いたままになっていないか、または、消費されたメッセージが未通知のままになっていないかを確認できます。これらのコーディングエラーはブローカのリソースを消費し、パフォーマンスに大きな影響を及ぼします。

基準になる使用パターンは、最適なパフォーマンスを得るためにシステムを調整する方法を決定する上で役立ちます。たとえば、次のように指定します。

一般に、使用パターンをより綿密に理解しているほど、より適切に、使用パターンに応じてシステムを調整し、将来ニーズに合わせてプランニングすることができます。