Confluence 用のパフォーマンステストフレームワーク

パフォーマンステストフレームワークは以前、Elastic Experiment Executor (E³ ) と呼ばれていました。これは、Confluence Data Center 製品のインスタンスをセットアップ、実行し、負荷状態でのパフォーマンスを分析するためのフレームワークです。

このページでは、Confluence での実験の実行について説明します。

We no longer use the Atlassian Performance Testing framework for our own performance tests. You can still use the framework, but we won’t be able to provide support or help you interpret the results.

On this page:

はじめる前に

実験を実行する前に、パフォーマンステストフレームワークの前提条件をすべて満たしていることを確認し、パフォーマンステストフレームワークのセットアップを行う必要があります。

開始方法については、「アトラシアンパフォーマンステストフレームワーク」を参照してください。

実験を定義する

実験は、以下を定義する JSON ファイルで記述されます。

(並列して) 実行される独立した実験スレッド
テストするインスタンスのタイプ
テストするインスタンスのサイズと形状
インスタンス内のデータの形状 (プロジェクト、リポジトリ、ユーザーなど)
インスタンスに負荷をかけるクライアントマシンのサイズと形状
ワークロードの操作の組み合わせ
実験の各ステージで適用される負荷の量 (クライアントスレッドの数)

e3-home/experiments には事前定義済みの実験用ライブラリがあります。独自に定義することもできます。

実験用の JSON ファイルで参照されるワークロードは e3-home/workloads で定義されます。

実験のフェーズ

パフォーマンス実験には、次のスクリプトに対応する複数のフェーズがあります。

Provision.py: 本番インスタンス、ワーカーマシンのクラスタ、および AWS 内のその他の関連インフラストラクチャをスピンアップします。実験用定義から e3-home/runs に自動的に "実行ファイル" を作成します。
Run.py: ワーカーマシンからクライアントワークロードを実際に実行します (また、ステージ間で本番インスタンスを既知の安定した状態にリセットします)。
Gather.py: 実行された実験 (実行中または完了済み) のデータをすべてのマシンから収集します。
Analyze.py: 実行された実験のデータを分析してグラフ化し、インスタンスのパフォーマンス状態や負荷状態における全インスタンスの "バイタルサイン" の視覚化をサポートします。
Deprovision.py: テストマシンのプロビジョニングを解除し、実験の実行をアーカイブします。

これらすべてのフェーズを順に実行するグローバル Orchestrate.py スクリプトに加えて、各フェーズは個別でも実行できます。

$ cd ./e3
$ ./Provision.py -e <experiment_name>
$ ./Run.py -r <run_name>
$ ./Gather.py -r <run_name>
$ ./Analyze.py -r <run_name>

ワークロード

ワークロードは、実験で使用する実行スクリプトのタイプと分散を定義します。1 つの実験で定義できるワークロードは 1 つのみですが、各ワークロードには複数のスクリプトを含めることができます。ワークロード記述子は e3-home/workloads に保存されます。

ワークロードの説明に含まれるもの:

script: 実験中に実行されるスクリプトのパス。e3/execution/grinder ディレクトリの相対パス。
description: 説明の名前。分析で生成されるグラフで使用されます。
scale: 分析ステージで適用される、実験での相対的な重み付け。重要度の低いオペレーションや負荷の低いオペレーションを視覚的に目立たせないようにするために使用できます。
weight: この実行スクリプトに適用される重み付け。すべての重みの合計値が 1.0 になるようにします。

重み

パフォーマンステストフレームワークがクライアントスレッドとワーカーに処理を割り当てる方式では、重み付けの方法をワークロードの定義に合わせて調整する必要があります。これを示す例は次のとおりです。

experiment.json

{
    ...
    "stages": [
        {
            "clients": 10
        },
        {
            "clients": 20
        }
    ]
}

上記で定義した実験は 10 クライアントのみのステージで実行されているため、重み付けで対応できる最大の解決状況は 1/10 または 0.1 です。そのため、0.1 未満の重みのスクリプトを含むワークロードの定義は実行できない場合があります。

また、フレームワークは、すべてのワーカーマシンでクライアントスレッドを均一に分散させます。つまり、各ステージで多数のクライアントスレッドを指定する場合、割り当てたワーカーマシンの数で除算できる数にする必要があります。

分析

パフォーマンステストフレームワークでは、ワーカーマシンや本番環境マシンから収集されたデータからグラフを生成できます。2 種類の分析スクリプトが付属します。

gnuplot
rrdtool

./e3/Analyze.py -r <run_name> を呼び出すと、特定の実行に対するタイプとグラフの両方が生成されます。

1 タイプのグラフのみを生成する場合:

$ ./e3/analysis/gnuplot/Analyze.py -r <run_name>

または

$ ./e3/analysis/rrdtool/Analyze.py -r <run_name>

生成されたグラフは e3-home/runs/<run_name>/analysis ディレクトリに保存されます。

注: 実験を実行した後に rrdtooll と gnuplot の両方からグラフを生成するには、Analyze.py スクリプトを使用する必要があります。Orchestrate.py は現在、rrdtool を使用するグラフのみを生成します。分析と、フレームワークで生成されるグラフのタイプに関する詳細については、Analysis/README.md にある専用の README を参照してください。

Confluence のデータセット

実験でさまざまな負荷テストを行うために、Confluence インスタンス用の複数のデータセットを用意しています。

インスタンスは、Confluence の実験ファイルで指定した場所にある space-import.zip.xml ファイルを使用して入力されます。既定では、これは Confluence の resources ディレクトリです。このファイルを独自のスペースエクスポートファイルと置き換えることができますが、既存のスペースにはテスト中にスクリプトで使用される特定のコンテンツが含まれるため、この方法は推奨されません。

構成のカスタマイズ

パフォーマンステストフレームワークでは、カスタムデータセット以外に、製品インスタンスの形状やサイズ、および負荷テストの性質を微調整できる、製品固有の追加カスタム構成もサポートします。

基本的な実験のブレークダウン

以下の基本的な実験は、Grinder と Confluence という 2 つの構成コンポーネントで構成されます。それぞれのカスタム構成は以下のとおりです。

{
    "product": "Confluence",
    "duration": 180000,
    "workload": "confluence-mixed",
    "threads": [
        {
            "name": "1-node",
            "instance": {
                "name": "1-node",
                "version": "6.1.0",
                "template": "ConfluenceDataCenter",
                "properties": [
                    "confluence.data.directory=resources/confluence",
                    "confluence.license.key=<license-key-string>",
                    "confluence.number.of.instances=1",
                    "confluence.number.of.users=60",
                    "confluence.min.users.to.run.experiment=60"
                ]
            },
            "worker": {
                "name": "2-node-worker-cluster",
                "template": "WorkerCluster",
                "parameters": {
                    "ClusterSize": "2"
                }
            },
            "stages": [
                {
                    "clients": 20
                },
                {
                    "clients": 40
                },
                {
                    "clients": 60
                }
            ]
        }
}

Grinder のカスタム構成

次のプロパティは、Grinder で実行する負荷テストの方法を指定します:

duration: 負荷テストの実行期間 (ミリ秒単位)
workload: 各実験スレッドで実行するワークロードの名前 (e3-home/workloads](./e3-home/workloads) で定義)
worker: クライアント構成
- ClusterSize: Confluence インスタンスに対してスクリプトを実行するクライアントとして動作するノード数を指定
stages: 1 つのインスタンスの実験の連続実行回数、および各ステージでシミュレーションを行うクライアントの数

Confluence のカスタム構成

次のプロパティを指定して、Confluence インスタンスをカスタマイズできます。

version: スピンアップする Confluence の製品バージョン
properties: Confluence がセットアップ中に使用するプロパティの一覧
- confluence.data.directory: Confluence のセットアップデータ (スペースのインポートやカスタムメールサーバー構成を含む) を見つけることができる、e3-home への相対パス
- confluence.license.key: Confluence インスタンスのセットアップに必要なライセンス (注: json ではスラッシュをエスケープする必要があります)
- confluence.number.of.instances: セットアップする Confluence クラスタのサイズ
- confluence.number.of.users: すべてのステージにわたる、1 つの実験スレッドでシミュレーションされるクライアントの最大数
- confluence.min.users.to.run.experiment: セットアップエラーが発生した場合に実験の実行に必要となる作成済みユーザーの最小数。既定値は 0 で、ユーザーをまったく作成できなかった場合でも実験の実行を試みます。
- mailtrap.api.token: メール通知の負荷テストに使用するための MailTrap サーバーを指定するオプションパラメータ。トークンが提供されない場合は、既定のカスタムメール構成ファイル mail-server.properties が設定されます。

独自のインフラストラクチャを使用する

AWS を使用したくない場合、パフォーマンステストフレームワークで独自のインフラストラクチャに対してテストを実行することができます。現在、Linux システムのみがサポートされます。これを行うには、以下が必要です。

パフォーマンスメトリックの収集に使用された製品インスタンスと追加ソフトウェアをセットアップおよび構成します。
製品インスタンスを記述する構成ファイルを作成します。
負荷を生成するワーカークラスターを構成し、それについて説明する構成を記述します。
パフォーマンステストを記述する実験ファイルを作成します。

Confluence インスタンスのセットアップ

次のセクションでは、パフォーマンスメトリックのレポートを行いながら実験リクエストを送信できるように Confluence をセットアップするためにあたり、必要な手順について説明します。

注: セットアップの一環として、新規テストユーザーを作成し、テストデータを削除/インポート/変更するためのフレームワークの認証資格情報を提供する必要があります。パフォーマンステストフレームワークを重要なデータを含むインスタンスで使用する際は、最初に Confluence のバックアップを行うことを強くお勧めします。

クラスター内の各ノードの認証に使用する公開鍵と秘密鍵のペアを作成します。すべてのクラスターノードで同じキーペアを使用する必要があります。
上記のキーペアを使用して e3-user をセットアップします。
Confluence クラスターインスタンスを処理する各ノードで SSH デーモンが実行中であることを確認する
お使いの Confluence インスタンスの JMX 監視を有効化します (ほとんどの Confluence バージョンでは既定で有効化されています)
セキュアな管理者セッション (WebSudo) を無効化、リモート API を有効化、およびオンボーディングプラグインを無効化するように Confluence インスタンスを構成します。オプションとしてメールサーバーをセットアップします。
PTF マシンから ./e3/util/AddUsers.py を実行して、Confluence インスタンスでテストユーザーをセットアップします。Confluence のベース URL、実験でスピンアップするクライアントの最大数、および適切なユーザー作成権限を持つ認証資格情報を渡す必要があります。所有しているライセンスが、テストユーザーの作成数に対応できることを確認します。
使用例:
```
$ ./e3/util/AddUsers/py --product Confluence --url http://localhost:8090/confluence --users 100
```
collectd デーモン (バージョン 5.2 以降) をインストールし、このリポジトリにサンプルとして含まれている confluence-collectd.conf 構成ファイルを使用して構成します。Linux ディストリビューション / collectd インストールに応じて調整が必要となる場合があります。詳細について、専用の config/README.md を参照してください。テストを開始する際にデーモンが実行中であることを確認します。
Confluence インスタンスを記述する json ファイルを作成し、次のフィールドを含めます。 ClusterNodes 接続文字列の一覧、Confluence サーバーの URL。
e3-home/instances ディレクトリに、インスタンスを記述する json ファイルとインスタンスの秘密鍵ファイルの両方をコピーします。両方のファイルは同じ名前でそれぞれ異なる拡張子 (.json および .pem) を使用する必要があります。

2 ノードの Confluence の構成ファイルの例

{ 
  "ClusterNodes": [ 
  "e3-user@confluence-server-node-1", 
  "e3-user@confluence-server-node-2" 
  ], 
  "URL": "http://confluence-server" 
}

ワーカーノードを構成する

このセクションでは、本番環境インスタンスに負荷を与えると同時に、実験を理解するうえで便利なメトリックを収集する、ワーカークラスターのセットアップに必要な手順について説明します。

クラスター内の各ノードの認証に使用する公開鍵と秘密鍵のペアを作成します。すべてのワーカーノードで同じキーペアを使用する必要があります。

ワーカークラスターの各ノードで次の操作を行います。

以下をインストールします。
- git
- Java
- python 2.7
- collectd (バージョン 5.2 以降)
このリポジトリにテンプレートとして含まれている worker-collectd.conf 構成ファイルを使用して collectd をセットアップします。Linux ディストリビューション / collectd インストールに応じて調整が必要となる場合があります。詳細については、専用の config/README.md を参照してください。テストを開始する際にデーモンが実行中であることを確認します。
ワーカーノードで SSH デーモンが実行中であることを確認します。
sudo 権限で、このクラスタ用に作成した公開鍵 / 秘密鍵のペアを使用して認証できる e3-user を作成します。sudo コマンドを実行する際、パスワードは求められません。/etc/sudoers 構成を編集して e3-user ALL=(ALL) NOPASSWD:ALL などを含める必要がある場合があります。
e3-user をオーナーとして /media/data ディレクトリを作成します。
ワーカークラスターを記述する json ファイルを作成します。
インスタンスのワーカークラスタと秘密鍵ファイルを記述する json ファイルを e3-home/instances ディレクトリにコピーします。両方のファイルは同じ名前でそれぞれ異なる拡張子 (.json および .pem) を使用する必要があります。

ワーカークラスターの構成ファイルの例。

{ 
  "ClusterNodes": [ 
  "e3-user@worker-node-1", 
  "e3-user@worker-node-2", 
  "e3-user@worker-node-3", 
  "e3-user@worker-node-4" 
  ] 
}

実験ファイルの例

上記で作成したインフラストラクチャファイルを参照して、実験について記述します。パフォーマンステストフレームワークでインスタンスをプロビジョニングしようとしているわけではないため、上記の実験セクションで説明されたすべての情報は不要な場合があります。独自のインフラストラクチャで実験を実行するために必要な最小限の情報を含む実験ファイルの例を以下に示します。

{
  "product": "Bitbucket",
  "duration": 10000,
  "workload": "bitbucket-mixed",
  "threads": [
    {
      "name": "2-node",
      "instance": {
        "stack": {
          "Name": "two-node-cluster"
        }
      },
      "stages": [
        {
          "clients": 40
        }
      ],
      "worker": {
        "stack": {
          "Name": "four-node-worker"
        }
      }
    }
  ]
}

上記の Name フィールドは、クラスタやワーカー構成を含む json ファイルの名前を参照します。

実際の例を使用して実験を準備する

この例では、負荷レベルが増加する中で 2 ノードと 4 ノードのクラスターを比較する実験の実行方法を示します。

最初に、製品インスタンスの構成ファイルを定義します。

Two-node.json

{ 
  "ClusterNodes": [ 
    "e3-user@confluence-server-node-1", 
    "e3-user@confluence-server-node-2" 
  ], 
  "URL": "http://confluence-server-with-2-nodes",   
}

Four-node.json

{ 
  "ClusterNodes": [ 
    "e3-user@confluence-server-node-1", 
    "e3-user@confluence-server-node-2", 
    "e3-user@confluence-server-node-3", 
    "e3-user@confluence-server-node-4" 
    ], 
  "URL": "http://confluence-server-with-4-nodes", 
}

次に、ワーカーノードを定義します。

Two-node-worker.json

{ 
  "ClusterNodes": [ 
    "e3-user@worker-node-1", 
    "e3-user@worker-node-2", 
    "e3-user@worker-node-3", 
    "e3-user@worker-node-4" 
  ] 
}

および同一の four-node-worker.json

これらの 4 つのファイルとそれぞれの秘密 ssh 鍵を ./e3-home/instances にコピーし、ディレクトリに次の情報が含まれることを確認します。

two-node.json
two-node.pem
four-node.json
four-node.pem
two-node-worker.json
two-node-worker.pem
four-node-worker.json
four-node-worker.pem

my-experiment.json というファイル名で実験を定義します。この例では、5 つのステージで同時接続を 40 から 200 まで増加させます。それぞれのステージは 5 分間持続し、confluence-mixed ワークロードを実行します。

{
  "product": "Confluence",
  "duration": 300000,
  "workload": "confluence-mixed",
  "threads": [
    {
      "name": "2-node",
      "instance": {
        "stack": {
          "Name": "two-node"
        }
      },
      "stages": [
        { "clients": 40 },
        { "clients": 80 },
        { "clients": 120 },
        { "clients": 160 },
        { "clients": 200 }
      ],
      "worker": {
        "stack": {
          "Name": "two-node-worker"
        }
      }
    },
    {
      "name": "4-node",
      "instance": {
        "stack": {
          "Name": "four-node"
        }
      },
      "stages": [
        { "clients": 40 },
        { "clients": 80 },
        { "clients": 120 },
        { "clients": 160 },
        { "clients": 200 }
      ],
      "worker": {
        "stack": {
          "Name": "four-node-worker"
        }
      }
    }
  ]

}

実験の名前 (この場合は my-experiment) を使用して、./e3-home/runs ディレクトリに新しいフォルダを作成する必要があります。./e3-home/runs ディレクトリが存在しない場合は作成します。実験ファイルを ./e3-home/runs/my-experiment/ にコピーします。

実験を実行する

実験を実行する前に、「セットアップ」セクションの指示に従い、前提条件の製品がインストールされていることを確認してください。

パフォーマンステストフレームワークがステージ間で Confluence をリセットできるように、管理者のユーザー資格情報を提供する必要があります。e3 ディレクトリに移動して以下を実行します。

$ ./Run.py -r my-experiment -u <admin_username> -p <admin_password>

実験データを分析する

実験の実行が完了したら、パフォーマンステストフレームワークで収集されたデータを確認します。インスタンスやワーカーノードからデータを収集して分析する方法は非常に簡単で、e3 ディレクトリから次のコマンドを実行するだけです。

$ ./Gather -r my-experiment
$ ./Analyze -r my-experiment

データファイルと結果のグラフは、事前に作成した実験実行フォルダ (./e3-home/runs/my-experiment など) に保存されます。

サポート

The Performance Testing Framework is provided as is, and is not covered by Atlassian support. Our support team won't be able to assist you with interpreting the test results.

Head to the performance-testing-framework topic on Atlassian Community to see how others have been using the framework, share your experiences, and ask for help from the community.

製品

Jira Software

Jira Service Management

Jira Work Management

Confluence

Bitbucket

リソース

関連ドキュメント

コミュニティ

システムステータス

提案とバグ

Marketplace

請求とライセンス情報

Confluence 用のパフォーマンステストフレームワーク

アトラシアンパフォーマンステストフレームワーク

このページの内容

お困りですか?

はじめる前に

実験を定義する

実験のフェーズ

ワークロード

重み

分析

Confluence のデータセット

構成のカスタマイズ

基本的な実験のブレークダウン

Grinder のカスタム構成

Confluence のカスタム構成

独自のインフラストラクチャを使用する

Confluence インスタンスのセットアップ

ワーカーノードを構成する

実験ファイルの例

実際の例を使用して実験を準備する

実験を実行する

実験データを分析する

サポート

ページ

Viewport

Confluence

Confluence 用のパフォーマンステストフレームワーク

アトラシアン パフォーマンス テスト フレームワーク

このページの内容

関連コンテンツ

お困りですか?

はじめる前に

実験を定義する

実験のフェーズ

ワークロード

重み

分析

Confluence のデータセット

構成のカスタマイズ

基本的な実験のブレークダウン

Grinder のカスタム構成

Confluence のカスタム構成

独自のインフラストラクチャを使用する

Confluence インスタンスのセットアップ

ワーカー ノードを構成する

実験ファイルの例

実際の例を使用して実験を準備する

実験を実行する

実験データを分析する

サポート

関連コンテンツ

アトラシアンパフォーマンステストフレームワーク

ワーカーノードを構成する