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

このページの内容

お困りですか?

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

コミュニティに質問

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.4

. 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. JIRA クラスタリングを提供する JIRA Data Center を使用します。

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 やグループに登録されているユーザー数。
    • ボード数、およびボード上の課題数 (JIRA Software を使用している場合)。
  • 使用パターン
    • JIRA を同時に使用しているユーザー数。
    • 同時操作の数。
    • 電子メール通知の量。
  • 構成
    • プラグインの数 (一部は独自のメモリ要件を持っている場合がある)。
    • ワークフロー ステップ実行の数 (移行や事後操作など)。
    • ジョブの数とスケジュールされたサービス。
  • デプロイメント環境
    • 使用されている JIRA のバージョン。
    • JIRA が実行されているサーバー。
    • 使用されているデータベースとデータベースへの接続性。
    • オペレーティングシステム (ファイルシステムを含む)。
    • JVM 構成。

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

テスト環境

パフォーマンステストはすべて、同じラボ (アトラシアンが管理する隔離されたラボ) で実施しました。テストのたびに環境全体をリセットおよび再構築し、各テストの最初にはインスタンスキャッシュをウォームアップするアイドルサイクルを実行しました。テストを実行するにあたり、スクリプトを組んだブラウザーを 10 個使用して負荷を生成し、操作の実行にかかる時間を計測しました。各ブラウザーのスクリプトは、定義済みの操作リストからランダムに操作を実行し、すぐに次の操作に移る (つまり思考時間ゼロ) ように組まれています。これにより、実際のユーザーが実行できるタスク数を大幅に上回るタスクを各ブラウザーで実行することができました。ただし、ブラウザーの数が実環境の同時ユーザーの数と等しいと解釈してはならないことに注意してください。各テストは 4分間実行され、その後で統計情報を収集しました。 


テスト環境の詳細についてはここをクリックしてください
ハードウェア ソフトウェア
CPU x2: Intel(R) Xeon(R) CPU E5-2430L 0
@ 2.00GHz
オペレーティング システム Ubuntu Server 12.04 LTS
CPU コア: 12x データベース MySQL 5.5
CPU スレッド: 24x Java Platform Java 1.8.0
メモリ: 6x 8GB DIMM DDR3 1333 MHz ブラウザ Chrome


JIRA 7.4.0 vs 7.3.0 performance

In this section, we’ll compare JIRA 7.4.0 to JIRA 7.3.0. Specifically, we ran the same extensive test scenarios for both JIRA versions. The only difference between the scenarios was the JIRA version. 

The scenarios were focused either on different data sets used by JIRA, or different actions performed.


データセット

The following chart presents mean response times for a JIRA instance that used various data sets, a different one in each test. We wanted to show how particular data dimensions affect the performance of JIRA, that’s why instead of testing particular actions, we tested a mean of all actions (see Actions) for each data set. The data sets contained a different number of issues, workflows, users, and so on. You can check what exactly was in each of them below the chart.

各データセットの応答時間

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


基本データセットの詳細...

We needed to determine what size and shape of data set represents a typical large JIRA instance. 

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

The following table presents rounded values of the 999th permille of each data dimension. We used these values to generate a sample data set with random test data in  JIRA Data Generator .

JIRA data dimension
課題 1,000, 000
プロジェクト 1500
カスタムフィールド 1400
ワークフロー 450
添付ファイル 660,000
コメント 2,900, 000
アジャイルボード 1,450
Users 100,000
グループ 22,500
セキュリティ レベル 170
権限 200
残りのデータセットの作成方法の詳細...

他のデータセットはすべて、基本データセットから取得しました。各データセットの 1 つの属性を 2 倍にして、他のすべての属性はそのままにしました。たとえば、"プロジェクト" データセットではプロジェクトの数 (3000) を、"ワークフロー" データセットではワークフローの数 (900) を 2 倍にしました。"全データセット" はすべてのデータセットの平均であり、「操作」セクションの各操作の応答時間をテストする際の基準として使用されます。

これについて説明するために、次の表に "課題" データセットを示します。

JIRA data dimension
課題 2,000, 000
プロジェクト 1500
カスタムフィールド 1400
ワークフロー 450
添付ファイル 660,000
コメント 2,900, 000
アジャイルボード 1,450
Users 100,000
グループ 22,500
セキュリティ レベル 170
権限 200
結論

JIRA 7.4 scales better with issues and agile boards, but not with other data dimensions. On average, the difference is less than 1%.


操作

The following chart presents mean response times for different actions performed in JIRA. In this case, we wanted to show how particular actions affect the performance of JIRA, and we tested them on a mean of all data sets (see Data sets). An "action" in this context is a complete user operation like opening of an Issue in the browser window. You can check the details of these actions below the chart.

各操作の応答時間

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


Jira 操作の詳細...

次の表は、ペルソナのテスト用にスクリプトに含めた操作の詳細と、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 回のテストの間に実行したすべての操作の平均。データセット」セクションの各データセットの応答時間を調べるための基準として使用されます。 -


結論

Response times for all tested actions are slightly slower in JIRA 7.4. On average, the difference is less than 1%.


その他のリソース

課題をアーカイブする

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 Data Center

JIRA Data Center is the ideal solution to use when you have a high number of concurrent users. JIRA Data Center allows the JIRA application to be clustered in a multi-node cluster where all nodes are active. This means that with a load balancer in front you can distribute the load across multiple nodes thereby increasing throughput when compared to a single server handling the same load. JIRA Data Center 7.4 also provides High Availability, and is the only fully Atlassian supported option for JIRA Disaster Recovery

Please refer to our main page for more information on JIRA Data Center.

ユーザー管理

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

Jira のナレッジベース

For detailed guidelines on specific performance-related topics refer to the Troubleshoot performance issues in Jira server article in the JIRA Knowledge Base.

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

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

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

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

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

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

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