Skip to end of metadata
Go to start of metadata

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. Yet there are so many other elements that can affect the scale of a JIRA instance.

This document explains how JIRA performs in different configurations and provides a guide of how to scale JIRA in a large enterprise. So whether you are a new JIRA evaluator that wants to understand how JIRA can scale to your needs, or you're a long time existing JIRA administrator that is interested taking JIRA to the next level, this page is here to help.

To scale JIRA in your organization, there are two key approaches, which can be used in combination to scale JIRA across your entire organization:  

  1. Scaling a single JIRA instance. 
  2. Federation: Using multiple, connected JIRA instances

We'll detail the first technique to get the most out of JIRA for your organization. The second technique is described in the Federating JIRA - Managing Multiple Instances guide.

Scaling a single JIRA instance

There are many factors that can affect JIRA's performance from the number of projects/issues to your backend configuration and also how you use the system.  Apart from issues and projects, here are some of the factors that impact performance in JIRA - in no particular order:

  • Data
    • The number of issues stored in JIRA
    • The number of attachments stored in JIRA
  • Usage
    • 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.
    • The number of JIRA Project elements that are configured, such as custom fields, issue types, and schemes.
  • Hardware / Operating System
    • 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

Existing customer examples

We regularly survey our customers to get an accurate picture of our customer’s environments and what difficulties they face when scaling JIRA in a large organisation. To give you an idea of the scale of several larger JIRA instances, on the right is a table with just a few examples of customers' production JIRA instances as they currently stand today and below is the 80th percentile of > 30 customers surveyed, all of whom have over 200,000 issues in their JIRA instance.

JIRA Configuration Item80th Percentile
Issues466,000
Custom Fields617
Users10,500
Permission Schemes43
Projects558
Parent Issue Types95
Resolutions16
Priorities6
Workflows68

(info) Issues are only one dimension that can affect JIRA's performance, to accurately gauge how a large instance will perform you will need to consider all of the factors.

Example Customer Production Instances

IssuesCustom FieldsUsersPermission SchemesProjectsParent Issue TypesResolutionsPrioritiesWorkflows
840,0006006,5001029016010510
800,0003101,0001439569010510
705,00060013,000354255010535
530,0005408,000456107015585
455,0002352,7001652502035535
390,0007555,600100475952020360
360,00070012,0002008002502010150
330,00061535,0002510905485100
225,000271593,00065311561565
205,0003006,000251904510535

You can sort this table by clicking on the headings.

 

Customer database usage

Along with our survey on JIRA configuration for customers with over 200,000 issues in their JIRA instance, we also collected their choice of database.

  • 38% of those customers Oracle, 38% used mySQL, with MS SQL at 14% and PostgreSQL at 10%.
  • The top 10 largest JIRA instances are evenly split between Oracle and mySQL, with no other supported database appearing in the top 10. Oracle and mySQL are evenly distributed among the top 10 as well, i.e. the top 5 are not all one database.

JIRA Project Configuration

Because of the flexibility of JIRA, there is a tremendous amount of variety across our customers' configurations.

However, there are some approaches to project configuration which will have a larger impact on performance than others. On the right is a table that shows you the results of a simple performance test that measures JIRA's throughput when certain configurations are doubled. Thoroughput in this context equates to operations per second. Operations are actions we think a normal user would perform such as: creating/editing/searching issues, viewing reports, viewing the dashboard and view project.

The configurations that affect JIRA the most are:

  • Issues
  • Custom Fields

On top of that we know that these two things also affect overall JIRA performance:

  • Permissions
  • Concurrent Users

(info) The take away from this is to keep your JIRA configuration lean. By the time your instance reaches some of these levels you would have been using JIRA for many years and things can grow stale. We strongly suggest that you re-use schemes where possible rather than creating new schemes and delete anything that is no longer needed.

ProjectsWorkflowsUsersIssue
Types
ResolutionsCustom
Fields
IssuesThroughput
Result
250305,0005510300200,00030 -baseline
500305,0005510300200,00030
250605,0005510300200,00030
2503010,0005510300200,00030
250305,00011010300200,00030
250305,0005520300200,00029
250305,0005510600200,00022
250305,0005510300400,00020
 Click here to see what hardware we used in these tests
Chassis:Dell Precision T5500
CPUs:2x Intel(R) Xeon(R) CPU E5640 @ 2.67GHz
Memory:12GB DDR3 SDRAM, 1333Mhz
Bridge/Chipset:Intel 5520
Storage:1x WDC WD3000HLFS, 04.04V03
NICs:1x Broadcom NetXtreme BCM5761
Operating SystemDebian GNU/Linux
DatabasePostgreSQL
BrowserReplicating the behaviour of FireFox


Archiving Issues

Although the number of issues is just one dimension that can affect JIRA's performance, by far it will be the dimension with the highest value. From the chart on the right you can see how the number of issues affect performance. One method to combat this is to have an archiving strategy. There are two common methods that our customers have reported using.

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.

(info) Think about what issues you really need to have on hand in your JIRA instance and ask yourself, "Do I really need to have all 800,000 issues in my production instance when I know it affects performance?".

Archiving for performance - request for interest

If you are looking to archive issues or projects for performance reasons then you may be interested in a new solution that Atlassian is building. At the moment we are interested in speaking with customers who would like to increase their current JIRA performance to see if they can benefit from the solution we are building. If this is of interest to you please send an email to roy at atlassian dot com with the subject: JIRA Performance and Roy will respond accordingly.



Note: this instance was tested with a different set of configurations to the baseline table above.

How custom fields affect performance

Custom fields can be configured in a variety of ways including: setting the applicable context; field configurations; screen schemes; and of course the three in various combinations. Below are the results of our performance testing with JIRA 5.1.3 and a few of the ways you can can configure custom fields. 

Custom Fields with global contexts

In this test we had all the custom fields set to global just to see how much of an impact the raw number of custom fields have on performance. You can see the results on the right for testing on the following four areas:

  1. Issue navigator - simple search
  2. Issue navigator - advanced search (JQL)
  3. View project (browse project summary screen)
  4. View issue

(info) When using global contexts for custom fields the upper range is around 600 and going beyond that you will start seeing performance hits.

 
The 300/450/600 data sets are all generally returning results in the same range, the variance there is natural noise. It's only past 600 custom fields where JIRA starts to slow down.

 

 

Custom Fields with field configurations

In this test we wanted to see if there was any affect on performance when field configurations are used to configure custom field display. For the chart to the right, an explanation of the legend is below:

  • Proj = Project context was used.
  • Glob = Global context was used.
  • FC = Field configurations were used.
    • Where FC was not mentioned, field configurations were not used.
  • S# = Data set number (two data sets were generated for testing).
  • R# = Run number for test (set 2 was run twice).

(info) A good way to make JIRA more performant when you have more than 600 custom fields is to use project contexts with the minimum amount of field configurations.

 

 
The charts above are all based on using 600 custom fields, 200 screen schemes, and 20 custom fields per screen.

Further resources

JIRA Federation

One recommendation to further scale JIRA is to federate. See the Federating JIRA - Managing Multiple Instances Enterprise Guide for more information.

User Management

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

JIRA Enterprise 

Please see the Enterprise Resources page for more guides on topics such as failover, staging servers, performance tuning, and much more.

Atlassian Experts

Of course you don't need to do any of this on your own. We have Atlassian Experts in your local area that can help you scale JIRA in your own environment. 

  • No labels