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

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

JIRA 7.7 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.7 to JIRA 7.6. 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 操作の応答時間

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

テスト手法

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

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)

JIRA 7.7 の拡張性

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

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

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

テスト方法

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 ユーザー ベースが増加すると、以下を確認する必要が出る場合があります。

• 認証、ユーザーおよびグループ管理のため、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 の拡大をサポートできます。