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

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.

はじめに

一部の 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 個使用して負荷を生成し、操作の実行にかかる時間を計測しました。各ブラウザーのスクリプトは、定義済みの操作リストからランダムに操作を実行し、すぐに次の操作に移る (つまり思考時間ゼロ) ように組まれています。これにより、実際のユーザーが実行できるタスク数を大幅に上回るタスクを各ブラウザーで実行することができました。ただし、ブラウザーの数が実環境の同時ユーザーの数と等しいと解釈してはならないことに注意してください。各テストは 45 分間実行され、その後で統計情報を収集しました。 

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.

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

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

結論

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.

各操作の応答時間

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

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)

結論

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 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 を LDAP ディレクトリに接続する。
• ユーザー管理のために Crowd または別の JIRA Server に接続する 。
• 他のアプリケーションに対し、ユーザー管理のために 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 の拡大をサポートできます。