We’re committed to continuously evolving and enhancing the quality of our performance reports. This report presents a comprehensive overview of the performance metrics for the most recent 10.3 Long Term Support (LTS) release of Jira Software Data Center.

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

We recommend upgrading Jira Software regularly, but if your organization's process means you only upgrade about once a year, upgrading to a Long Term Support release is a good option. It provides continued access to critical security, stability, data integrity, and performance fixes until this version reaches end of life.

要約

In the Jira 10.3 release, we’re showcasing the results of our performance testing through a new framework that focuses on Non-Functional Requirements (NFR) thresholds for essential user actions. These thresholds serve as benchmarks for reliability, responsiveness, and scalability, ensuring that our system adheres to the expected performance standards. We've successfully delivered features that significantly impact the product and consistently addressed performance regressions to pass all NFR tests. You can be confident that as the product evolves and you scale, we’ll remain dedicated to optimizing and maintaining the performance.

Testing overview

テスト手法

The test scenarios were all run simultaneously using scripted browsers. Each browser was scripted to execute one of the scenarios listed below repeatedly and without thinking time until at least 1000 results were gathered per scenario.

テスト環境

The performance tests were all run on a set of AWS EC2 instances, deployed in the eu-west-1 region. The tested Jira instance was an out-of-the-box fresh Jira Data Center installation setup as a single node and without any additional configuration. This approach allowed us to ensure satisfying performance in a basic setup with more nodes adding additional performance gains if necessary.

Below, you can check the details of the environments used for Jira Software Data Center and the specifications of the EC2 instances. Hardware sizes were either reduced or not increased with the introduction of the new testing framework.

データベース

ロード ジェネレーター

テスト データ セット

Before we started testing, we needed to determine what size and shape of the dataset represents a typical large Jira Software instance. To achieve that, we created a new dataset that more accurately matches the instance profiles of Jira Software in very large organizations.

The data was collected based on the anonymous statistics received from real customer instances. A machine-learning (clustering) algorithm was used to group the data into small, medium, large, and extra-large instances data shapes. For our tests, we decided to use median values gathered from extra-large instances.

The new dataset significantly increases some dimensions, such as the number of issues, comments, attachments, projects, agile boards, and workflows, compared to the dataset previously used to create the release performance reports. Some dimensions have slightly decreased, but the new values better reflect real-life customer statistics or match our guardrails.

The following table presents the dataset we used in our tests. It simulates a data shape typical in our extra-large customer cohort.

Testing results

NFR tests

This year, we've introduced a set of test scenarios based on a framework that focuses on Non-Functional Requirements (NFR) thresholds for key user actions.

We've established a target threshold for each measured action. These thresholds, set according to the action type, serve as benchmarks for reliability, responsiveness, and scalability, ensuring that our product meets the expected performance standards. We're committed to ensuring that we don’t deliver performance regressions, maintaining the quality and reliability of our product.

The measured performance of the action was defined as the time from the beginning of an action (for example, initiating browser navigation for View actions or submitting a form) until the action is performed and the crucial information is visible (for example, the Issue summary, description, and activity are displayed for the View Issue action). Thanks to this approach, we can more closely measure the performance as it's perceived by the end user.

The following interpretations of the response times apply:

• 50th percentile - Gives a clear understanding of the average performance for most users in extra-large instances. It's less affected by extreme outliers, so it shows the central tendency of response times.

• 90th percentile - Highlights performance for worst-case scenarios, which may affect a smaller, but still noteworthy, portion of users in the extra-large instances.

注意:

• We routinely carry out internal performance testing to ensure that all actions remain within the NFR thresholds. Our continuous monitoring enables us to optimize performance and effectively address any regressions.

• All actions had a 0% error rate, demonstrating strong system reliability and stability. For the list of bugs resolved since the previous 9.12 LTS, refer to the Jira Software 10.3 LTS release notes.

The results overall are as follows:

Further resources for scaling and optimizing

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

課題をアーカイブする

The number of issues affects Jira's performance, so you might want to archive issues that are no longer needed. You may also conclude 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. Learn more about archiving projects

Jira Software のガードレール

Product guardrails are data-type recommendations designed to help you identify potential risks and aid you in making decisions about the next steps in your instance optimization journey. Learn more about Jira Software guardrails

Jira ナレッジベース

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

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

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

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

The Atlassian Experts in your local area can also help you scale Jira in your own environment.