Scaling Jira 6.4


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 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.

On this 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 number of issues on the board (when you're using Jira Agile).
  • 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 local file storage, memory allocation, and garbage collection.

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

Jira 6.4 performance

Jira 6.4 brings significant performance improvements that have a considerable impact on the performance of large scale instances. In this section, we will compare the results of performance tests of a single large Jira instance using Jira 6.3 as our baseline vs. the more recently released Jira 6.4 version. You can compare these results to your own Jira instance to predict the potential improvement you might expect from upgrading to Jira 6.4.

Specifically, we carried out two series of performance tests to determine current Jira performance (Jira 6.4) and then compared it to previous Jira version (Jira 6.3). All other testing environment settings, including the reference dataset configuration (outlined above) and persona scenarios, were the same in both series. 

The following chart presents average response times of individual actions achieved during the tests.


Performance Testing Conclusions:

  • On average, performing the test actions in Jira 6.4 was over 30% faster than Jira 6.3.
  • As you can see from the performance tests most of our performance improvement work in 6.4 provides benefits for the most often used actions such as; viewing all Issues, going to the Dashboard, and searching for Issues was nearly two times faster in Jira 6.4.
  • Going to Agile Board was also noticeably faster.
  • Thanks to newly implemented pagination and filtering options, browsing through Projects and Agile Boards, was both more user friendly and faster. 

Jira performance 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 dataset represents a typical large Jira instance. 

In order to achieve that, we surveyed our customers to form a picture of our customers' environments and what difficulties they face when scaling Jira in a large organization. The following table combines approximate data from the 75th percentile of 30 of our largest customer instances that participated in the survey. We then used these values to generate a sample dataset with random test data in Jira Data Generator

Baseline test Jira data set

Jira Configuration Item Value
Issues 700,000
Projects 850
Custom Fields 820
Workflows 225
Attachments 465,000
Comments 1,500,000
Agile Boards 1,000
Users 43,000
Groups 4,100
Security Levels 19
Permissions 37
See examples of existing customers instances...

The table below contains a few examples of customers' production Jira instances as they currently stand today. It is worth noting that the values of individual configuration items don't grow linearly with the number of Issues.

(info) The data we ask for can be easily seen in your own instance by going to   > System > System Info > Database Statistics.

Example Customer Production Instances

Issues Projects Custom Fields Workflows Attachments Comments Users Groups
503,000 322 220 231 209,000 1,937,000 19,845 2,875
775,000 420 297 53 755,000 51,000 44,026 83
686,200 1,002 679 377 288,00 705,000 21,168 31,493
366,326 120 480 37 472,000 1,442,000 6,265 608
558,324 1,061 513 155 214,000 972,000 25,283 510
1,443,000 203 136 31 4,922,000 162,000 16,428 876
734,000 828 401 242 341,000 1,179,000 2,600  


Next 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 action is performed during a single test run
View Dashboard Opening of the Dashboard page. 10
Create Issue Opening of Create Issue dialog, filling in Summary and Description, and submitting. 5
View Issue Opening of an individual issue in separate browser window. 55
Edit Issue Editing Summary, Description and some fields of an existing Issue. 5
Add Comment Adding Comment to an Issue. 2
View All Issues Opening of the list of all Issues (available under Issues > Search for issues menu) 10
Search with JQL Performing search query using JQL in Issue Navigator interface 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) 1

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 predefined list of actions and immediately move on to the next action (i.e. 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 15 minutes, after which statistics were collected. 

Click here for details of our test environment
Hardware Software
CPU x2: Intel(R) Xeon(R) CPU E5-2430L 0
@ 2.00GHz
Operating System Ubuntu Server 12.04 LTS
CPU Cores: 12x Database MySQL 5.5
CPU Threads: 24x JAVA platform Java 1.8.0
Memory: 6x 8GB DIMM DDR3 1333 MHz Browser Chrome

Jira 6.4 scalability 

Because of the flexibility of Jira, there is a tremendous amount of diversity across our customers' configurations. According to our findings, nearly every customer has a unique characteristic of their datasets. One characteristic that we noticed was; that as customers' Jira instances grow, it is quite rare that the values of all data attributes grow proportionally to each other. Instead, it is often the case that one or a couple of attributes become significantly bigger than what could be expected from the sizes of remaining data attributes. For instance we can observe massive growth in the of number of issues, while the number of projects remains stable; or we can see an extremely large number of custom fields for a given number of issues in the Jira instance. There were little similarities in the ratio of the various configuration items we looked at.

This is understandable and desired behavior, because each organization has their own unique processes and needs and Jira is unique in its ability to support these various use cases. On the other hand, the increasing size of data influences the speed of Jira, which may result in longer response times of Jira actions performed by its users. This influence however, is not equal or linear for every data attribute, ie. some configuration values exert stronger influences on Jira performance than others. 

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 attributes influence the speed of the application. In this section we will present the results of Jira 6.4 scalability tests that investigated the relative impact of various configuration values. 

How we tested

As a reference for the test we used a Jira 6.4 instance with the baseline test data set specified above and ran the full performance test cycle on it. 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. 

In the charts below we present how the response times of Jira actions change for growing size of individual data attributes.

In order to provide a clearer view, each graph shows only the actions for which the difference of response time was greater than the variance of natural noise caused by the randomness of the tests procedure.


There is a common belief amongst seasoned Jira Admin's in large organizations that the number of issues is the most important factor affecting Jira performance; in other words, when an individual Jira instance reaches a couple hundred thousands of issues it will start becoming unresponsive. While this was generally true in older Jira versions, starting from Jira 5.1 the number of issues became less and less important for the overall Jira responsiveness. That number still affects the speed of actions that require indexing of issues, but the degradation is not severe and Jira 6.4 can handle more than a million Issues.

The following chart presents response times of Jira actions in Jira 6.4 instances with 700,000 and 1,400,000 issues. 


  • the number of issues has highest impact on search with JQL, create issue, edit issue and add comment actions
  • the number of issues seems to have a limited negative effect on actions such as open dashboard, view all issues, view issue, browse projects, browse boards 

Custom Fields

Custom fields can be configured in a variety of ways including setting the applicable context, field configurations and screen schemes, and including the three of them in various combinations. In this test we had all the custom fields set to global in order to see how much of an impact the raw number of custom fields has on performance.

The following chart presents response times of Jira actions in Jira 6.4 instances with 820 and 1,640 custom fields.


  • the number of custom fields has highest impact on the actions that request or process custom issue details, i.e view all issues, search with JQL, create issue, edit issue
  • the number of custom fields seems to not have a negative effect on actions independent on custom issue details, such as open dashboard, view issue, browse projects, project summary, browse boards 


The following chart presents response times of Jira actions in Jira 6.4 instances with 850 and 1,700 projects. 


  • the number of projects has highest impact on the actions related to project count, i.e view all issues, search with JQL, create issue, browse projects
  • the number of projects seems to not have a negative effect on actions independent on project count and performed in the context of single project, such as open dashboard, view issue, edit Issue, project summary, browse boards 

Users and Groups

Number of users, next to the number of issues, is one of the most commonly customer quoted examples of Jira instance size. When evaluating the influence of the number of users on Jira's performance, it is important to separate the number user accounts registered in Jira from the number of users actively using Jira at the same time, known as concurrent users. In this test we wanted to determine the influence of the absolute number of users and groups registered in Jira, without increasing the number of concurrent users.  For a large number of concurrent Jira users we suggest considering the Jira Data Center solution, which allows the Jira application to be clustered in a multi-node cluster with a load balancer to distribute the load across the cluster.  

The following chart presents response times of the create issue action in a Jira 6.4 instance with 43,000 users and 4,000 groups compared to 80,000 users and 8,000 groups. 


  • the absolute number of registered users and groups does not seem to have a significant impact on Jira performance, other than for issue creation.
  • however, the load put on Jira from the increased number of concurrent users impacts the overall Jira performance. Please refer to the Jira Data Center Performance page to understand the nature of this impact.


The following chart presents the response times of Jira actions in Jira 6.4 instances with 225 and 450 workflows.


  • the number of workflows primarily affects the actions that request available workflows from Jira, i.e create issue, edit issue
  • the number of workflows does not correlate to a negative effect on the overall Jira performance (apart from the two create and edit issue actions)

Agile Boards

The following chart presents response times of Jira actions in Jira 6.4 instances with 1,000 and 2,000 Agile boards.


  • the number of boards only marginally affects the create issue action, as well as those that refer to the boards count, ie. browse boards and project summary
  • the number of boards seems not to have a negative effect on other actions outside Agile, and it does not affect operations performed within the context of single board

Permissions and Security Levels

The following chart presents response times of Jira actions in Jira 6.4 instances with 19 security levels and 37 permissions compared to 39 security levels and 77 permissions. 


  • the number of global security levels and permissions seems to affect only the create issue and search for issues actions, since these two operations require cross checking of all the permission schemes.

Key takeaways

  • When we tested some of the most commonly used actions in Jira 6.4 we saw a 30% improvement in average response times compared to Jira 6.3. Given how flexible & configurable Jira is and how diverse our customers are, there is no completely accurate way of forecasting how much or how little of this 30% improvement an individual customer will experience. Hopefully this page has given insight into some of the factors that determine the performance improvements a customer may experience on 6.4. Performance continues to be a key focus for Jira and we'd love to hear your feedback on your experience post upgrade to 6.4. 
  • The values of attributes, which directly correspond to the size of your Jira instance, (i.e. number of issues and number of projects) have some effect on the time to complete certain operations in Jira. However, even for instances that are as big as nearly 1.5 million issues or 1,700 projects, the response times were less than 4 seconds. 
  • The configuration attributes that affect Jira speed the most are custom fields and workflows. In particular, they impact the time of the create issue operation, which is one of the most important for Jira users. That means it is still a good practice to keep your Jira configuration lean. Limiting the number of custom fields and workflows, as well as reusing schemes where possible, not only helps your Jira instance keep satisfactory performance levels, but also makes administration less complicated.
  • The testing did not show the number of comments or attachments to have any impact on performance.  Testing was done with 500,000 and 1M attachments as well separately with 1.5M and 3M comments and we did not observe any negative impact.  


Please note that all of these conclusions come from performance test results carried out with Jira 6.4 where we introduced significant optimizations for Jira performance in large scale server instances. In particular:

  • the acceleration effect presented with response times of Jira 6.3 and Jira 6.4 may not be that evident in small scale Jira Server instances
  • the response times values and scalability consequences do not apply to Jira versions lower than 6.4
  • the response times and scalability consequences do not apply to Jira Cloud
  • the testing instance did not have any plugins installed other than Jira Agile, therefore the results do not reflect the impact that user-installed plugins have on Jira

Further resources

Archiving Issues

Although we discovered that the number of issues is not significantly affecting Jira's performance, by far it will be the dimension with the highest value. You may 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. 

Read about the two common methods to archive Jira Issues....

Backup and Delete - one Jira instance

This is the quickest and easiest of the two methods. You simply take a Jira backup of the entire instance, label the backup with the date and then store it in a secure location. Test that the backup can be restored on a Jira test instance. Once you are satisfied that it all works you can go ahead and delete the projects or issues that are no longer in use. Deleting can also extend to the other dimensions such as custom fields, schemes, etc.

Although quick and easy, the downside to this method is that when you users request to see an archived issue you will need to find the appropriate backup and then restore it to another Jira instance. This is the best method to use if you do not anticipate a large number of archive retrieval requests.

Migrate and Delete - two Jira instances

This method is much more complicated. First, you will initially take a full backup, then restore this into a separate Jira instance. Verify that everything has come across. Once you are happy you will keep the issues you want to archive in this instance and delete everything else. For future archiving sessions you will go to your production instance and create a filter for all the issues you want to archive. Move these issues into a separate project and then take a full backup of your Jira instance. You will then use Jira's project restore to import this project into the archive instance where you can then move these issues into their respective projects.

Although this method takes up a lot more time and resources, the main advantage is that you will essentially have a live archive instance that your users can visit anytime they want to see an archived issue.


For more information, see Backing Up Data.


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 6.4 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:

Jira Knowledge Base

For detailed guidelines on specific performance-related topics refer to JIRA applications performance tuning articles in 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 Jan 12, 2018

Was this helpful?

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