Performance and scale testing

With every JIRA release, we’re publishing a performance and scaling report that compares performance of the current JIRA version with the previous one. The report also contains results of how various data dimensions (number of custom fields, issues, projects, and so on) affect JIRA, so you can check which of these data dimensions should be limited to have 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 is not 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 that wants to understand how JIRA can scale to your growing needs or you're a seasoned JIRA administrator that is 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 which provides JIRA clustering.

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

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
  • The number of issues, comments, and attachments.
  • The number of projects.
  • The number of JIRA project attributes, such as custom fields, issue types, and schemes.
  • The number of users registered in JIRA and groups.
  • The number of boards, and the number of issues on the board (when you're using JIRA Software).
• Usage patterns
  
  • The number of users concurrently using JIRA.
  • The number of concurrent operations.
  • The volume of email notifications.
• Configuration
  • The number of plugins (some of which may have their own memory requirements).
  • The number of workflow step executions (such as Transitions and Post Functions).
  • The number of jobs and scheduled services.
• Deployment environment
  
  • 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.

This page will show how the speed of JIRA can be influenced by the size and characteristics of data stored in the database.

Test environment

Our performance tests were all run on the same controlled isolated lab at Atlassian. For each test, the entire environment was reset and rebuilt, and then each test started with some idle cycles to warm up instance caches. To run the tests, we used 10 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 (ie. 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. Each test was run for 45 minutes, after which statistics were collected. 

JIRA 7.5.0 vs 7.4.0 performance

In this section, we’ll compare JIRA 7.5.0 to JIRA 7.4.0. Specifically, we ran the same extensive test scenarios for both JIRA versions. The only difference between the scenarios was the JIRA version. 

The scenarios were focused either on different data sets used by JIRA, or on different actions performed.

Data sets

The following chart presents mean response times for a JIRA instance that used various data sets, a different one in each test. We wanted to show how particular data dimensions affect the performance of JIRA, that’s why instead of testing particular actions, we tested a mean of all actions (see Actions) for each data set. The data sets contained a different number of issues, workflows, users, and so on. You can check what exactly was in each of them below the chart.

Response times per data set

Each row represents mean response times. The lower the value, the better the performance.

Conclusion

Performance of JIRA 7.5 is comparable to that of JIRA 7.4, regardless of the data set used. On average, the difference is less than 1%, mostly visible with issues, custom fields, and users & groups.

Actions

The following chart presents mean response times for different actions performed in JIRA. In this case, we wanted to show how particular actions affect the performance of JIRA, and we tested them on a mean of all data sets (see Data sets). An "action" in this context is a complete user operation like opening of an Issue in the browser window. You can check the details of these actions below the chart.

Response times per action

Each row represents mean response times. The lower the value, the better the performance.

description ~ 'totally' or summary ~ 'hobos' and comment !~ 'propel' ORDER BY key

reporter was in (admin) and status = Closed order by createdDate

comment ~ 'contest* saw' and reporter was admin order by assignee desc

text ~ 'a* ba*' ORDER BY Status, summary

priority was in (Low, Lowest) or (status = 'In Progress' and assignee changed) or createdDate > '2016/07/02 00:00'

resolution = Unresolved and priority = Low

text ~ 'witch* doctrine' and status was not Closed order by priority

project = novemcinctus and assignee = admin ORDER BY assignee

assignee in membersOf('users_1') order by project

not (status = closed and resolution = Done and priority = High)

Conclusion

Response times in JIRA 7.5 are comparable to those in JIRA 7.4, regardless of the actions performed. On average, the difference is less than 1%, mostly visible with such actions as viewing the dashboard or the project summary.

Further resources

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. 

JIRA Data Center

JIRA Data Center is the ideal solution to use when you have a high number of concurrent users. JIRA Data Center allows the JIRA application to be clustered in a multi-node cluster where all nodes are active. This means that with a load balancer in front you can distribute the load across multiple nodes thereby increasing throughput when compared to a single server handling the same load. JIRA Data Center 7.5 also provides High Availability, and is the only fully Atlassian supported option for JIRA Disaster Recovery. 

Please refer to our main page for more information on JIRA Data Center.

User Management

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

• Connecting JIRA to your LDAP 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, reach out to our Premier Support and Technical Account Management services.

Atlassian Experts

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