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

はじめに

When some Jira administrators think about how to scale Jira, they often focus on the number of issues a single Jira instance can hold. However, the number of issues isn’t the only factor that determines the scale of a Jira instance. To understand how a large instance may perform, you need to consider multiple factors.

This page explains how Jira performs across different versions and configurations. So whether you are a new Jira evaluator who wants to understand how Jira can scale to your growing needs or you're a seasoned Jira admin who’s interested in taking Jira to the next level, this page is here to help.

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

1. 単一の Jira インスタンスを拡張する
2. クラスタ化されたマルチノード設定で 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 の速度に影響を与える可能性があります。多くの場合、これらの影響は一定または直線的ではありません。

To provide an optimal experience and avoid performance degradation, it’s important to understand how specific data dimensions impact speed.

ご利用の組織で Jira のパフォーマンスに影響を与える可能性がある要因は複数あります。こうした要因は、次のようなカテゴリーに分類されます (順不同)。

• データ サイズ (次に示す項目の数):
  • issues
  • コメント
  • attachments
  • プロジェクト
  • プロジェクト属性 (カスタム フィールド、課題タイプ、スキームなど)
  • 登録されたユーザーとグループ
  • ボード
  • 任意のボード上の課題 (Jira Software の場合)
• 使用パターン (次に示す項目の数または規模):
  • Jira に同時にログインしているユーザー
  • 同時操作
  • メール通知
• 設定 (次に示す項目の数):
  • プラグイン (一部は独自のメモリ要件を持っている場合がある)
  • workflow step executions (such as transitions and post functions)
  • ジョブとスケジュールされたサービス
• デプロイ環境:
  • 使用している Jira のバージョン
  • Jira を実行しているサーバー
  • 使用しているデータベースとデータベースへの接続性
  • オペレーティング システム (そのファイル システムを含む)
  • JVM 設定

The following sections will show you how Jira's speed can be influenced by the size and characteristics of data stored in the database.

テスト手法

まずは、パフォーマンス テストで採用したテスト方法と、使用したテスト環境のハードウェア仕様をご説明します。

テスト データ セット

テストを開始する前に、一般的な大規模な Jira インスタンスを表すデータ セットのサイズと形状を決定する必要がありました。

To achieve that, we collected analytics data to get an idea of our customers' environments and what difficulties they face when scaling Jira in large organizations. Then, we rounded the values of the 999th permille of each data dimension included in the tests and used an internal data generation solution to generate a random test data set.

The following table lists the exact number of elements in each data dimension.

実行した操作

次の表は、テスト ペルソナのシナリオに含まれるアクションの割合を示しており、テスト中に各アクションが実行された回数の割合を表しています。「アクション」とは、課題を開くこと、コメントの追加、ブラウザー ウィンドウでのバックログ表示など、完全な操作を意味します。

テスト環境

パフォーマンス テストは、eu-west-1 リージョンにデプロイされた一連の EC2 インスタンス上ですべて実行しました。テストごとに、環境全体のリセットと再ビルドを行いました。

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

各テストを 20 分間行ったあと、統計情報を収集しました。

Jira Server 環境の構成内容:

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

Jira Data Center 環境の構成内容:

• Jira ノード 2 つ
• 別のノード上にあるデータベース
• 別のノード上にあるロード ジェネレーター
• 別のノード上にある共有ホーム ディレクトリ
• Load balancer (Apache Load Balancer running on EC2)

Jira Server と Jira Data Center でパフォーマンス テストを実行するために使用した各 EC2 インスタンスのハードウェア仕様の簡単な要約を次に示します。

結果

このセクションでは、さまざまな設定値の相対的な影響を調査するために実施した、すべての拡張性テストの結果をご説明します。テスト プロセスは次のとおりです。

1. テストの参考として、上述したベースライン テスト データ セットを含む Jira インスタンスを使用して、パフォーマンス テスト サイクル全体を実行しました。 

2. データ ディメンションとそれらのパフォーマンスへの影響に焦点を当てるため、個々のアクションをテストする代わりに、パフォーマンス テストのすべてのアクションの平均値を算出しました。

3. Next, we doubled each attribute in the baseline data set and ran independent performance tests for each doubled value while leaving all the other attributes in the baseline data set unchanged. That is, we ran the test with a doubled number of issues or a doubled number of custom fields. To reduce noise, we repeated the tests until the results reached a state of convergence. In other words, a state in which the difference in the aggregated mean response time for each data dimension didn’t exceed 10 ms with each subsequent test run.

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

Finally, here are the response times per data set. To give you a bigger picture view of how Jira’s responsiveness has changed over time, we’re publishing comparisons between Jira 9.12.0 and Jira 9.4.12 as well as Jira 8.20.28.

Comparison of response times per data set between Jira 9.12.0 and Jira 9.4.12

The exact response time values from the chart above are listed in the following tables.

Jira Server 9.12.0 と Jira Server 9.4.12 の比較

応答時間の単位はすべてミリ秒です。

Jira Data Center 9.12.0 と Jira Data Center 9.4.12 の比較(2 ノード)

応答時間の単位はすべてミリ秒です。

Comparison of response times per data set between Jira 9.12.0 and Jira 8.20.28

The exact response time values from the chart above are listed in the following tables.

Jira Server 9.12.0 と Jira Server 8.20.28 の比較

応答時間の単位はすべてミリ秒です。

Jira Data Center 9.12.0 と Jira Data Center 8.20.28 の比較(2 ノード)

応答時間の単位はすべてミリ秒です。

Jira Data Center における Advanced Roadmaps のパフォーマンス

Advanced Roadmaps のパフォーマンスに影響する要因

Jira Data Center インスタンスにおける Advanced Roadmaps のパフォーマンスに関する最大の変動要因は、単純に含まれる情報の量です。Advanced Roadmaps のプランはいくつかの Jira 機能で構成されており、プランを作成するときにそれぞれを個別に実行する必要があります。プランが実行する関数が多いほど、読み込みにかかる時間が長くなります。

インスタンスにおける Advanced Roadmaps の速度は、次の要素によって決まります。

• インスタンス内の課題の数
• インスタンスにある課題リンクと依存関係の数
• 各プランの課題数
  • 「Advanced Roadmaps のプラン」の「プラン サイズの制限」セクションを参照
• プランに含まれる課題ソースの数と、その JQL の複雑さ
  • 「Jira Server の JQL パフォーマンスに寄与する要因」を参照
• 階層の設定
• プランで有効化して使用しているカスタム フィールド
• プラン内のバージョンとリリースの数
  • 「多くのリリースを読み込むと、ポートフォリオ プランの操作が遅い」をご確認ください。

テスト方法

このページの「テスト手法」セクションで説明されているハードウェアと手法を含む、Jira パフォーマンス テスト フレームワークを使用しました。

テスト インスタンスの内容は次のとおりです。

• 課題 1,000,000 件
• 100,000 ユーザー

テスト プランの内容は次のとおりです。

• 500 件の課題
• 5 件の課題ボード課題ソース
• 5 件のチーム (課題ソースあたり 1 件)
• 5 レベルの課題階層
• 80 件のリリース/バージョン
• 0 件のプラン カスタム フィールド

Jira Data Center 9.7.0 における Advanced Roadmaps の要約メトリック

Jira Data Center 9.7.0 に含まれているバージョンの Advanced Roadmaps は、上記の基準に基づいて次の読み込み時間を記録しました。

改善された (3.x) インターフェイスを使用中のプラン

単位はすべてミリ秒です。

レガシー (2.x ライブ プラン) インターフェイスを使用中のプラン

単位はすべてミリ秒です。

その他のリソース

Jira の拡張と最適化について詳しく知りたい場合は、その他のリソースもご参考ください。

課題をアーカイブする

課題の数は Jira のパフォーマンスに影響するため、不要になった課題のアーカイブが望ましい場合があります。また、Jira のビューに多数の課題が表示され、不要になった古い課題をインスタンスからアーカイブしたい場合があります。「プロジェクトのアーカイブ」を参照してください。

ユーザー管理

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

• 認証、ユーザー、グループ管理のために Jira をディレクトリに接続します。
• ユーザー管理のために Crowd または別の Jira Server に接続する 。
• 他のアプリケーションに対し、ユーザー管理のために Jira への接続を許可する。 

Jira ナレッジベース

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

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

お客様の組織内の Jira のスケーリングを経験豊富なアトラシアン社員が直接サポートする方法については、追加サポート サービスをご覧ください。

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

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