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.

Introduction

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.

There are two main approaches, which can be used in combination to scale Jira across your entire organization:  

1. Scale a single Jira instance
2. Use Jira Data Center in a clustered multi-node configuration

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.

Determining the scale of a single Jira instance

Jira's flexibility causes significant diversity in our customer's configurations. Analytics data shows that nearly every customer data set displays a unique characteristic. Different Jira instances grow in different proportions of each data dimension. Frequently, a few dimensions become significantly bigger than the others. In one case, the issue count may grow rapidly, while the project count remains constant. In another case, the custom field count may be huge, while the issue count remains small.

Many organizations have their own unique processes and needs. Jira's ability to support these various use cases explains the diversity of the data set. However, each data dimension can influence Jira's speed. This influence is often neither constant nor linear.

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

There are multiple factors that may affect Jira's performance in your organization. These factors fall into the following categories (in no particular order):

• Data size, meaning the number of:
  • issues
  • comments
  • attachments
  • projects
  • project attributes (such as custom fields, issue types, and schemes)
  • registered users and groups
  • boards
  • issues on any given board (in the case of Jira Software)
• Usage patterns, meaning the number or volume of:
  • users concurrently logged into Jira
  • concurrent operations
  • email notifications
• Configuration, meaning the number of:
  • plugins (some of which may have their own memory requirements)
  • workflow step executions (such as transitions and post functions)
  • jobs and scheduled services
• Deployment environment:
  • The Jira version used
  • The server Jira runs on
  • The database used and connectivity to the database
  • The operating system, including its file system
  • JVM configuration

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

Testing methodology

Let’s start with a description of the testing methodology we followed in the performance tests and the hardware specifications of the testing environment we used.

Test data set

Before we started the test, we needed to determine what size and shape of the data set represents a typical large Jira instance.

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.

Actions performed

The following table provides the proportions of actions included in the scenario for our testing persona, representing the percentage of times each action is performed during the test. By “action”, we mean a complete operation like opening an issue, adding a comment, or viewing the backlog in a browser window.

Test environment

The performance tests were all run on a set of EC2 instances, deployed in the eu-west-1 region. For each test, the entire environment was reset and rebuilt.

To run the tests, we used 20 scripted browsers and measured the time taken to perform the actions. Each browser was scripted to perform a random action from a predefined list of actions and immediately move on to the next action (that is, zero think time). Please note that it resulted in each browser performing substantially more tasks than would be possible by a real user and you should not equate the number of browsers to represent the number of real-world concurrent users.

We ran each test was run for 20 minutes and after that, statistics were collected.

The Jira Server environment consisted of:

• One Jira node
• Database on a separate node
• Load generator on a separate node

The Jira Data Center environment consisted of:

• Two Jira nodes
• Database on a separate node
• Load generator on a separate node
• Shared home directory on a separate node
• Load balancer (Apache Load Balancer running on EC2)

Below is a brief summary of the hardware specifications of each EC2 instance we used to run performance tests on Jira Server and Jira Data Center:

Results

In this section, we present the results of all the scalability tests we performed to investigate the relative impact of various configuration values. This is the process we followed:

1. As a reference for the test, we used a Jira instance containing the baseline test data set outlined previously and ran the full performance test cycle on it. 

2. To focus on data dimensions and their effect on performance, instead of testing individual actions, we calculated a mean of all actions from the performance tests.

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 a comparison between Jira 9.14.0 and Jira 9.12.4.

Comparison of response times per data set between Jira 9.14.0 and Jira 9.12.4

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

Jira Data Center 9.14.0 (1 node) vs. Jira Server 9.12.4

All response times in ms.

Jira Data Center 9.14.0 vs. Jira Data Center 9.12.4 (2 nodes)

All response times in ms.

Further resources

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 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. See Archiving projects.

User Management

As your Jira user base grows you may want to take a look at the following:

• Connecting Jira to your Directory for authentication, user and group management.
• Connecting to Crowd or Another Jira Server for User Management.
• Allowing Other Applications to Connect to Jira for User Management. 

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.