Jira Service Management 5.4.x 長期サポート リリースのパフォーマンス レポート

このページでは、Jira Service Management 4.20 と Jira Service Management 5.4 長期サポート リリースのパフォーマンスを比較しています。

長期サポート リリースについて

Jira Service Management を定期的にアップグレードすることをお勧めします。ただし、組織のプロセスによって年に 1 回程度しかアップグレードできない場合は、長期サポート リリースへのアップグレードが良い選択肢となります。これにより、該当するバージョンのサポート終了まで、重大なセキュリティ、安定性、データ整合性、パフォーマンスの問題に継続的に対応できるようになります。

パフォーマンス

アトラシアンは、他のすべての長期サポート リリースと同様に、これまでと同等かそれ以上のパフォーマンスを実現することを目標にしています。Jira Service Management 5.4 のテストでは、ワークロード レポートの表示およびアセットのインポートとスケーリングのパフォーマンスが大幅に向上したことがわかりました。また、カスタマー ページの表示、サービス課題の表示、カスタマー リクエストの作成においても、顕著な改善が見られました。

リクエストの表示、キューの表示、およびアセット オブジェクトの作成で、パフォーマンスがいくらか低下しました。これらは、Jira Service Management 4.20 LTS 以降に製品で行われた機能の改善に起因する可能性があります。

このセクションでは、Server と Data Center の両方について、Jira Service Management 4.20 を Jira Service Management 5.4 と比較します。両方のバージョンについて、4 つのカテゴリに分けられる広範なテスト シナリオを実行しました。

• 軽量な操作

• 中程度の操作

• 重い操作 (実行に時間がかかる)

• Insight の操作 (アセット管理機能に関連)

パフォーマンスは、5000 ユーザーのインスタンスでピーク トラフィックと推定されるユーザー負荷下で計測されました。操作やテスト方法の詳細については、「テスト手法」をご確認ください。

軽量な操作

グラフは、個々の操作の応答時間の違いを示しています。グラフの作成に使用されたデータは下部で確認できます。

中程度の操作

グラフは、個々の操作の応答時間の違いを示しています。グラフの作成に使用されたデータは下部で確認できます。

重い操作

グラフは、個々の操作の応答時間の違いを示しています。グラフの作成に使用されたデータは下部で確認できます。

アセット操作

グラフは、個々の操作の応答時間の違いを示しています。グラフの作成に使用されたデータは下部で確認できます。

アセットのインポート速度とスケーリング

製品でのユーザー操作のパフォーマンスに加えて、アセットでのメモリの使用方法、インポートの実行方法、および一括操作の処理方法も改善されています。

• インポート オブジェクトの作成が 55-70% 速くなりました。

• 大規模なデータセットに対して必要になるメモリが 20-35% 減りました。

• アセットのインデックス再作成が 10 倍速くなりました。

• 複雑なオブジェクト タイプ階層のクエリとインポートが最大で 25 倍速くなりました*。

• アセットのユーザー インターフェイスによるオブジェクトの一括削除が 4.8 倍速くなりました。

• インポートをメモリではなくディスクにオフロードするということは、アセットが以前よりもはるかに大きなインポートに対応できるようになったことを意味します。

^{* National Vulnerability Database (NVD) のインポート速度で実証されています。}

概要

パフォーマンスは高負荷下においても製品全体でおおむね安定しており、いくつかの改善が見られました。主に注目すべき点を次に示します。

• ワークロード レポート (中) の表示が 19.4 倍速くなりました。

• カスタマー ページの表示が 1.1 倍速くなりました。

• サービス課題の表示が 1.2 倍速くなりました。

• カスタマー リクエストの作成が 1.1 倍速くなりました。

• インポート オブジェクトの作成が 55-70% 速くなりました。

• 大規模なデータセットに対して必要になるメモリが 20-35% 減りました。

リクエストの表示、キューの表示、およびアセット オブジェクトの作成で、パフォーマンスがいくらか低下しました。これらは、新しいリクエスト リスト機能 (4.21 および 5.3)、SLA の計算精度を向上させるために加えられた変更 (5.0)、およびアセットのアクセシビリティとユーザー インターフェイスのさまざまな改善 (5.0、5.1、5.2、5.3) に起因する可能性があります。

アトラシアンでは、サービス チームがワークスペース内を簡単に移動でき、最大規模のお客様が自信を持って拡張できるよう、パフォーマンスのさらなる改善に向けて今後も取り組んでいく予定です。

テスト手法

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

テスト方法

テストを開始する前に、一般に大規模な Jira Service Management インスタンスを表すデータセットのサイズと内容を決定する必要がありました。これを実現するために、アナリティクス データを使用して、お客様の環境の全体像を把握したり、大規模な組織で Jira Service Management を拡張する際にお客様が直面する問題を特定したりしました。

また、Jira Service Management Data Center の一部となったアセットのデータ セットも用意しました。

次の表では、各データ ディメンションを 99 パーセンタイルの値で切り捨てています。これらの値を使用して、ランダムなテスト データを含むサンプル データセットを生成しました。

基準となるデータ セット

アセットのデータ セット

実行した操作

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

軽量、中程度、および重い操作

アセット操作

ユーザー操作のテスト環境

すべてのパフォーマンス テストは、一連の AWS EC2 インスタンス上で実行されました。テストごとに環境全体をリセットおよび再構築し、各テストの最初にはインスタンス キャッシュをウォームアップするためのアイドル サイクルを実行しました。以下で、Jira Service Management Server および Data Center で使用された環境の詳細や、EC2 インスタンスの仕様を確認できます。

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

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

ここでは、テスト環境の詳細について説明します。