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.

Summary

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

Testing methodology

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.

Test environment

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.

Database

Load generator

Test dataset

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.

Note that:

• 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

If you'd like to learn more about scaling and optimizing Jira, here are a few additional resources that you can refer to.

Archiving issues

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 guardrails

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 knowledge base

For detailed guidelines on specific performance-related topics refer to the Troubleshoot performance issues in Jira server article in the Jira knowledge base.

Jira Enterprise Services

For help with scaling Jira in your organization directly from experienced Atlassians, check out our Additional Support Services offering.

Atlassian Experts

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