パフォーマンスおよび拡張のテスト

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

With every JIRA release, we’re publishing a performance and scaling report that compares performance of the current JIRA version with the previous one. The report also contains results of how various data dimensions (number of custom fields, issues, projects, and so on) affect JIRA, so you can check which of these data dimensions should be limited to have best results when scaling JIRA.

This report is for JIRA 7.9. If you’re looking for other reports, select your version at the top-right.

はじめに

一部の JIRA 管理者は JIRA の拡張方法について考えたとき、1 つの JIRA インスタンスが保有できる課題数に焦点を与えることがよくあります。ただし、JIRA インスタンスの規模を決める要因は課題数のみではありません。大きなインスタンスの実行方法について理解するには、複数の要因を検討する必要があります。

このページでは、異なるバージョンや構成で JIRA を実行する方法について説明します。そのため、あなたがニーズの拡大に合わせて JIRA を拡大する方法について理解する新人 JIRA エバリュエータであっても、JIRA を次のレベルに進めることに関心を持つ熟練した JIRA 管理者であっても、このページが役に立ちます。

次の 2 つも主なアプローチを組み合わせ、組織全体で JIRA を拡大することができます。  

  1. 1 つの JIRA インスタンスを選択します。 
  2. Use JIRA Data Center which provides JIRA clustering.

Here we'll explore techniques to get the most out of JIRA that are common to both approaches. For additional information on JIRA Data Center and how it can improve performance under concurrent load, please refer to our JIRA Data Center page.

1 つの JIRA インスタンスの規模を決定する

組織内の JIRA のパフォーマンスに影響を与える可能性のある要因は複数あります。これらの要因は次のカテゴリーに分類されます (特定の順序はありません):

  • データ サイズ
    • 課題、コメント、および添付ファイルの数
    • プロジェクトの数。
    • JIRA プロジェクト属性の数 (カスタム フィールド、課題タイプおよびスキーム)。
    • JIRA やグループに登録されているユーザー数。
    • The number of boards, and the number of issues on the board (when you're using JIRA Software).
  • 使用パターン
    • JIRA を同時に使用しているユーザー数。
    • 同時操作の数。
    • 電子メール通知の量。
  • 設定
    • プラグインの数 (一部は独自のメモリ要件を持っている場合がある)。
    • ワークフロー ステップ実行の数 (移行や事後操作など)。
    • ジョブの数とスケジュールされたサービス。
  • デプロイメント環境
    • 使用されている JIRA のバージョン。
    • JIRA が実行されているサーバー。
    • 使用されているデータベースとデータベースへの接続性。
    • オペレーティングシステム (ファイルシステムを含む)。
    • JVM 構成。

このページは、データベースに保存されているデータのサイズや特徴によって、JIRA の速度がどのように影響を受けるかを示しています。

JIRA 7.9 performance

JIRA 7.9 was not focused solely on performance, however we do aim to provide the same, if not better, performance with each release. In this section, we'll compare JIRA 7.9 to JIRA 7.7. We ran the same extensive test scenario for both JIRA versions. The only difference between the scenarios was the JIRA version.

The following chart presents mean response times of individual actions performed in JIRA. To check the details of these actions and the JIRA instance they were performed in, see Testing methodology.


JIRA 操作の応答時間

各列は平均応答時間を示しています。値が小さいほどパフォーマンスが優れていることを表します。

ボードの改善

JIRA 7.9 では、ボードのパフォーマンスが約 30% 向上しました。これは、多くのエピックでボードに影響を与えたバグの修正によるものです。詳細について

テスト手法

以下のセクションでは、当社のパフォーマンス テストで使用するテスト環境 (ハードウェア仕様を含む) とテスト方法を詳しく説明します。


テスト方法...

Before we started the test, we needed to determine what size and shape of data set represents a typical large JIRA instance. 

これを実現するため、顧客環境の全体像や、大組織で JIRA を拡張する際に顧客が直面する問題を把握するため、Analytics データを使用しました。

次の表では、各データ ディメンションの 999 番目のパーセンタイルの値を切り捨てています。これらの値を使用して、JIRA Data Generator でランダム テスト データが入ったサンプル データセットを生成します。

Baseline JIRA data set

JIRA data dimension
課題 1,000, 000
プロジェクト 1500
カスタムフィールド 1400
ワークフロー 450
添付ファイル 660,000
コメント 2,900, 000
アジャイルボード 1,450
ユーザー情報 100,000
グループ 22,500
セキュリティ レベル 170
権限 200
実行した操作...

最も一般的なユーザー操作の例を表す混合操作を選択しました。このコンテキストにおける「操作」とは、ブラウザ ウィンドウで課題を開くなどの、完全なユーザー操作です。次の表は、ペルソナのテスト用にスクリプトに含めた操作の詳細と、1 回のテスト中に各操作が何回繰り返されるかを示しています。

操作名 説明 1 回のテストの間に操作を実行した回数
ダッシュボードの表示 ダッシュボード ページを開く。 10
課題の作成 課題の作成ダイアログを送信する 5
課題の表示 別のブラウザー ウィンドウで個別の課題を開く。 55
課題の編集 既存のフィールドのサマリー、説明およびその他のフィールドを編集する。 5
コメントを追加 課題へのコメント追加。 2
JQL の検索

課題ナビゲーター インターフェイスで JQL を使用して検索クエリを実行する。

次の JQL クエリが使用されました。
description ~ 'totally' or summary ~ 'hobos' and comment !~ 'propel' ORDER BY key
reporter was in (admin) and status = Closed order by createdDate

 

comment ~ 'contest* saw' and reporter was admin order by assignee desc

 

text ~ 'a* ba*' ORDER BY Status, summary

 

priority was in (Low, Lowest) or (status = 'In Progress' and assignee changed) or createdDate > '2016/07/02 00:00'

 

resolution = Unresolved and priority = Low

 

text ~ 'witch* doctrine' and status was not Closed order by priority

 

project = novemcinctus and assignee = admin ORDER BY assignee

 

assignee in membersOf('users_1') order by project

 

not (status = closed and resolution = Done and priority = High)

これらのクエリの半数は非常に重いため、平均応答時間の高さの原因となっています。

10
ボードの表示 Agile Board を開く 10
プロジェクトの参照 プロジェクトのリストを開く (プロジェクト > すべてのプロジェクトの検索メニューから利用できます) 5
ボードの参照 Agile Boards のリストを開く (Agile > ボードの管理メニューから利用できます) 2
すべての操作 1 回のテスト実行中に実行されたすべての操作の平均。 -
テスト環境...

The performance tests were all run on a set of AWS EC2 instances, deployed in the eu-central-1 region. For each test, the entire environment was reset and rebuilt, and then each test started with some idle cycles to warm up instance caches. Below, you can check the details of the environments used for JIRA Server and JIRA Data Center, as well as the specifications of the EC2 instances.

テストを実行するため、スクリプトを組んだブラウザを 10 個使用し、操作の実行にかかる時間を計測しました。各ブラウザーのスクリプトは、定義済みの操作リストからランダムに操作を実行し、すぐに次の操作に移る(つまり思考時間がゼロになる)ように記述されています。これによって各ブラウザは実際のユーザーが可能なタスクよりも実質的に多くのタスクを実行するため、ブラウザの数が実際の同時実行ユーザー数と等しくなると解釈することはできません。

各テストは 20分間実行され、その後、統計情報が収集されます。 


JIRA Server Jira Data Center

The environment with JIRA Server consisted of:

  • 1 JIRA node
  • 別のノード上にあるデータベース
  • 別のノード上にあるロード ジェネレーター

The environment with JIRA Data Center consisted of:

  • 2 JIRA nodes
  • 別のノード上にあるデータベース
  • 別のノード上にあるロード ジェネレーター
  • 別のノード上にある共有ホーム ディレクトリ
  • ロード バランサ (AWS ELB HTTP ロード バランサ)
Jira
ハードウェア ソフトウェア
EC2 タイプ:

c4.8xlarge (EC2 タイプを参照)  

JIRA Server: 1 node

JIRA Data Center: 2 nodes

オペレーティング システム: Ubuntu 16.04 LTS
CPU: Intel Xeon E5-2666 v3 (Haswell) Java プラットフォーム: Java 1.8.0
CPU コア: 36 Java オプション:

8 GB heap


メモリ: 60 GB
ディスク: AWS EBS 100 GB gp2
データベース
ハードウェア ソフトウェア
EC2 タイプ: c4.8xlarge (see EC2 types)   データベース: MySQL 5.5
CPU: Intel Xeon E5-2666 v3 (Haswell) オペレーティング システム:


Ubuntu 16.04 LTS


CPU コア: 36
メモリ: 60 GB
ディスク:

JIRA Server: AWS EBS 100 GB gp2

JIRA Data Center: AWS EBS 60 GB gp2

ロード ジェネレーター
ハードウェア ソフトウェア
EC2 タイプ: c4.8xlarge (see EC2 types)   オペレーティング システム: Ubuntu 16.04 LTS
CPU: Intel Xeon E5-2666 v3 (Haswell) ブラウザ: Google Chrome 62


CPU コア: 36 自動化スクリプト:

Chromedriver 2.33

WebDriver 3.4.0

Java JDK 8u131

メモリ: 60 GB
ディスク: AWS EBS 30 GB gp2

JIRA 7.9 の拡張性

JIRA は柔軟なため、顧客の構成にはとてつもない多様性があります。Analytics データは、ほとんどの顧客データセットが、独自の特性を示していることを示します。異なる JIRA インスタンスは、各データ ディメンションの異なる比率で増加します。いくつかのディメンションは他のディメンションより大幅に大きくなることが多くあります。たとえば、課題数が急速に増加する一方、プロジェクト数は一定数を維持することがあります。また、別の事例では、カスタム フィールドが膨大なのに、課題数が少なくなる場合があります。

多くの組織には独自のプロセスやニーズがあります。これらのさまざまな使用事例をサポートできる JIRA の能力が、データセットの多様性の理由となっています。ただし、各データ ディメンションは JIRA の速度に影響を与える可能性があります。多くの場合、これらの影響は一定または直線的ではありません。

それぞれの JIRA インスタンス ユーザーに最適な体験を提供し、パフォーマンスの劣化を防ぐため、具体的な JIRA データ属性がアプリケーションの速度にどのような影響を与えるかを理解することが重要です。このセクションでは、様アマナ構成値の相対的な影響を調査した JIRA 7.9 拡張性テストの結果を示します。 

テスト方法

As a reference for the test we used a JIRA 7.8 instance with the baseline test data set specified above and ran the full performance test cycle on it. To focus on data dimensions and their effect on performance, we didn't test individual actions, but instead used a mean of all actions. Next, in the baseline data set we doubled each attribute and ran independent performance tests for each doubled value (i.e. we ran the test with a doubled number of issues, or doubled number of custom fields) while leaving all the other attributes in the baseline data set unchanged. Then, we compared the response times from the doubled data set test cycles with the reference results. With this approach we could isolate and observe how the growing size of individual JIRA configuration items affects the speed of an (already large) JIRA instance. 

Response times for JIRA data sets

各列は平均応答時間を示しています。値が小さいほどパフォーマンスが優れていることを表します。

その他のリソース

課題をアーカイブする

The number of issues affects JIRA's performance, so you might want to archive issues that are no longer needed. You may also come to conclusion that the massive number of issues clutters the view in JIRA, and therefore you still may wish to archive the outdated issues from your instance. 

Jira 課題を達成するための 2 つの一般的な方法についてお読みください...

バックアップと削除 - 1 つの JIRA インスタンス

2 つの方法のうち、こちらのほうが素早く簡単です。インスタンス全体の JIRA バックアップを作成し、バックアップに日付のラベルを付けてから、安全な場所に保存するだけです。バックアップを JIRA テスト インスタンス上で復元できることをテストします。すべてが機能していることに満足したら先へ進み、使用しなくなったプロジェクトや課題を削除します。また、削除を、カスタム フィールドやスキーマなどの他のディメンションへと広げることもできます。

この方法は素早く簡単ですが、短所は、ユーザーがアーカイブされた課題の表示をリクエストすると、あなたが適切なバックアップを探し、別の JIRA インスタンスに復元する必要があるということです。多数のアーカイブ取得リクエストが来ることが懸念されない場合は最適な方法です。

移行と削除 - 2 つの JIRA インスタンス

この方法はより複雑です。最初に、フル バックアップを作成してから、それを別の JIRA インスタンスに復元します。すべてが見つかることを確認します。結果に満足したら、このインスタンスで達成する課題を保持し、それ以外をすべて削除します。将来のアーカイブ セッションでは、本番環境インスタンスに進み、アーカイブするすべての課題に対するフィルターを作成します。課題を別のプロジェクトに動かしてから、JIRA インスタンスのフル バックアップを作成します。次に、JIRA のプロジェクト復元を使用してこのプロジェクトをアーカイブ インスタンスにインポートし、そこでそれらの課題をそれぞれのプロジェクトに動かします。

この方法は多くの時間とリソースを消費しますが、主なメリットは、基本的に、ユーザーがアーカイブされた課題に椅子でもアクセスできるライブ アーカイブ インスタンスを持つということです。

詳細については、「データのバックアップ」を参照してください。

ユーザー管理

JIRA ユーザー ベースが増加すると、以下を確認する必要が出る場合があります。

Jira のナレッジベース

具体的なパフォーマンス関連のトピックの詳細なガイドラインについては、JIRA ナレッジベースのパフォーマンスの問題のトラブルシューティングの記事を参照してください。

JIRA エンタープライズ サービス

経験豊富なアトラシアンから直接組織内の JIRA の拡大のサポートが必要な場合は、プレミア サポートと技術アカウント管理サービスをご利用ください。

ソリューションパートナー

お住まいの地域のアトラシアン エキスパートも、お客様の環境での JIRA の拡大をサポートできます。 

最終更新日: 2019 年 2 月 11 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.