Performance and scale testing

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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.

This report is for Jira 7.13. If you’re looking for other reports, select your version at the top-right.

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.

Jira 7.13 performance

Jira 7.13 was not focused solely on performance, however we do aim to provide the same, if not better, performance with each release. In this section, we'll compare Jira 7.13 to Jira 7.12. We ran the same extensive test scenario for both Jira versions. The only difference between the scenarios was the Jira version.

The following chart presents mean response times of individual actions performed in Jira. To check the details of these actions and the Jira instance they were performed in, see Testing methodology.

Jira 7.13 vs Jira 7.12

Response times for Jira actions

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


Jira 7.13 vs Jira 7.6

Response times for Jira actions

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


In summary

  • Jira 7.13 shows significant improvement in response time when viewing boards (-28% Server, -27% Data Center)viewing backlogs (-9% Server, -13% Data Center)browsing boards (0% Server, -18% Data Center), and viewing project summary (-40% Server, -42% Data Center).

  • Most of the actions looks similar between the two versions. We’ve observed small performance degradation when viewing issues (+2% Server, -2% Data Center)viewing dashboards (+4% Server, +3% Data Center), browsing projects (+4% Server, +4% Data Center), adding comments (+10% Server, 0% Data Center) and searching with JQL (0% Server, +5% Data Center).

  • The mean of all actions has improved in Jira 7.13 (-3% Server, -4% Data Center)

Testing methodology

The following sections detail the testing environment, including hardware specification, and methodology we used in our performance tests.


How we tested...

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

In order to achieve that, we used our Analytics data to form a picture of our customers' environments and what difficulties they face when scaling Jira in a large organization.

The following table presents rounded values of the 999th permille of each data dimension. We used these values to generate a sample dataset with random test data in Jira Data Generator.

Baseline Jira data set

Jira data dimension Value
Issues 1,000,000
Projects 1500
Custom Fields 1400
Workflows 450
Attachments 660,000
Comments 2,900,000
Agile Boards 1,450
Users 100,000
Groups 22,500
Security Levels 170
Permissions 200
Actions performed...

We chose a mix of actions that would represent a sample of the most common user actions. An "action" in this context is a complete user operation like opening of an Issue in the browser window. The following table details the actions that we included in the script for our testing persona, indicating how many times each action is repeated during a single test run.

Action name Description Number of times an action is performed during a single test run
View Dashboard Opening the Dashboard page. 10
Create Issue Submitting a Create Issue dialog. 5
View Issue Opening an individual issue in a separate browser window. 55
Edit Issue Editing the Summary, Description and other fields of an existing Issue. 5
Add Comment Adding a Comment to an Issue. 2
Search with JQL

Performing a search query using JQL in the Issue Navigator interface.

The following JQL queries were used...
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)

Half of these queries are very heavyweight, which explains high average response time.

10
View Board Opening of Agile Board 10
Browse Projects Opening of the list of Projects (available under Projects > View All Projects menu) 5
Browse Boards Opening of the list of Agile Boards (available under Agile > Manage Boards menu) 2
All Actions A mean of all actions performed during a single test run. -
Test environment...

The performance tests were all run on a set of AWS EC2 instances, deployed in the eu-central-1 region. For each test, the entire environment was reset and rebuilt, and then each test started with some idle cycles to warm up instance caches. Below, you can check the details of the environments used for Jira Server and Jira Data Center, as well as the specifications of the EC2 instances.

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 20 minutes, after which statistics were collected. 


Jira Server Jira Data Center

The environment with Jira Server consisted of:

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

The environment with Jira Data Center consisted of:

  • 2 Jira nodes
  • Database on a separate node
  • Load generator on a separate node
  • Shared home directory on a separate node
  • Load balancer (AWS ELB HTTP load balancer)
Jira
Hardware Software
EC2 type:

c4.8xlarge (see EC2 types)  

Jira Server: 1 node

Jira Data Center: 2 nodes

Operating system: Ubuntu 16.04 LTS
CPU: Intel Xeon E5-2666 v3 (Haswell) Java platform: Java 1.8.0
CPU cores: 36 Java options:

8 GB heap


Memory: 60 GB
Disk: AWS EBS 100 GB gp2
Database
Hardware Software
EC2 type: c4.8xlarge (see EC2 types)   Database: MySQL 5.5
CPU: Intel Xeon E5-2666 v3 (Haswell) Operating system:


Ubuntu 16.04 LTS


CPU cores: 36
Memory: 60 GB
Disk:

Jira Server: AWS EBS 100 GB gp2

Jira Data Center: AWS EBS 60 GB gp2

Load generator
Hardware Software
EC2 type: c4.8xlarge (see EC2 types)   Operating system: Ubuntu 16.04 LTS
CPU: Intel Xeon E5-2666 v3 (Haswell) Browser: Google Chrome 62


CPU cores: 36 Automation script:

Chromedriver 2.33

WebDriver 3.4.0

Java JDK 8u131

Memory: 60 GB
Disk: AWS EBS 30 GB gp2

Jira 7.13 scalability

Jira's flexibility causes tremendous diversity in our customer's configurations. Analytics data shows that nearly every customer dataset 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 is small.

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

In order to provide individual Jira instance users with an optimum experience and avoid performance degradation, it is important to understand how specific Jira data dimensions influence the speed of the application. In this section we will present the results of the Jira 7.13 scalability tests that investigated the relative impact of various configuration values. 

How we tested

As a reference for the test we used a Jira 7.13 instance with the baseline test data set specified above and ran the full performance test cycle on it. To focus on data dimensions and their effect on performance, we didn't test individual actions, but instead used a mean of all actions. Next, in the baseline data set we doubled each attribute and ran independent performance tests for each doubled value (i.e. we ran the test with a doubled number of issues, or doubled number of custom fields) while leaving all the other attributes in the baseline data set unchanged. 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. 

Jira 7.13 vs Jira 7.12

Response times for Jira data sets

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


Jira 7.13 vs Jira 7.6

Response times for Jira data sets

In summary


  • The biggest improvement in response time has been observed in the following data sets: Issues (-7% Server, -4% Data Center), Agile Boards (-8% Server, -4% Data Center), Workflows (-5% Server, +1% Data Center), Projects (0% Server, -9% Data Center)

  • The baseline data set has improved in Jira 7.13 (-4% Server, -3% Data Center)

  • The mean of all data sets has improved in Jira 7.13 (-3% Server, -4% Data Center)

  • The only data sets that saw performance degradation are Custom Fields (only Server, +3%) and Workflows (only Data Center, 1%)

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

User Management

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

Jira Knowledge Base

For detailed guidelines on specific performance-related topics refer to the Troubleshooting Performance Problems 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. 

Last modified on Feb 11, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.