1. Homepage
  2. Mule Runtime (4.3)
  3. パフォーマンスチューニングガイド

  4. パフォーマンステスト検証

パフォーマンステスト検証

アプリケーションのパフォーマンスを検証する手順は次のとおりです。

  1. テストの前提条件を確認する。

  2. ベストプラクティスに従う。

  3. パフォーマンステストを実行する。

パフォーマンステスト検証の前提条件

パフォーマンステストを実行する前に、以下を行ってください。

  • Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。

  • 以下の質問を自問してパフォーマンステストの条件を確立します。

    • 平均とピーク時のワークロードは?

    • ユースケースで対処する必要のある特定のニーズは?

      • 大量のトランザクションを高優先度で処理する場合のスループット。

      • アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。

      • 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。

      • アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。

    • 許容できる最小スループットは?

    • 許容できる最大応答時間は?

パフォーマンステスト検証のベストプラクティス

テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。

制御された環境の使用

自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。

  • 3 台の専用ホストで構成されるインフラストラクチャを使用する:

    • オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。

    • 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。

    • データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。

    • オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。

    • CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。

  • 優先接続された安定したネットワークを使用する。

  • 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。

パフォーマンステストインフラストラクチャ
Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止)

適切なコンポーネントツールの選択

テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。

テストのコンポーネントの分離

パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。

代表的なワークロードの使用

アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。

  • ユーザーの動作

  • ワークロード (仮想ユーザー数、メッセージ数など)

  • ペイロード (種別、サイズ、複雑さ)

この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。

パフォーマンステスト検証の実行

テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。

  1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。

  2. 反復的なアプローチで、見つけた問題の改善に取り組みます。

    • CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。

    • オンプレミスアプリケーションの場合:

      1. Mule フローと設定をチューニングします。

      2. JVM、GC、などをチューニングします。

      3. オペレーティングシステム変数をチューニングします。

  3. テストを数回実行して、信頼できる結果を得ます。​「チューニングの推奨事項」​の項目を 1 つずつ変更してテストを再実行してください。

  4. テスト結果を確認します。