Scaling Jira 7.3

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 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 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 7.3 performance

Jira 7.3 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.3.0 to Jira 7.2.5. Specifically, 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 1%-trimmed mean response times of individual actions performed during the tests.

Response times for Jira actions

Performance Testing Conclusions:

• On average, Jira 7.3.0 performs actions 4% faster than Jira 7.2.5. This is based on the average time to complete an action, obtained from our tests described below.
• Most of the individual actions have very similar performance.
• Browsing agile boards is noticeably 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 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 Analytics data did not contain information about agile boards and attachments, so we extrapolated them from the Jira 6.4 scaling report by scaling them proportionally with issues.

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 test Jira data set

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.

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)

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

Jira 7.3 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.3 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.3 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.

Click here for full results of scalability tests...

Issues

There is a common belief among seasoned Jira admins 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 of hundred thousand issues it will start becoming unresponsive. While this was generally true in older Jira versions, since Jira 5.1 the number of issues has become 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 as severe and Jira 7.3 can handle more than a million Issues.

The following chart presents response times of Jira actions in Jira 7.3 instances with 1,000,000 and 2,000,000 issues. 
 

Conclusion

The number of issues has the highest impact on searching via JQL and viewing boards - actions reading from the issue index.

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 7.3 instances with 1,400 and 2,800 custom fields.
 

Projects

The following chart presents response times of Jira actions in Jira 7.3 instances with 1,500 and 3,000 projects. 

Conclusion

• The number of projects has visible impact on many aspects of Jira performance, most importantly on adding comments and browsing projects.
• Less impact has been observed on viewing, creating and editing issues.

Users and Groups

The 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 of 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 7.3 instance with 100,000 users and 22,500 groups compared to 200,000 users and 45,000 groups.

Conclusion

The number of users and groups negatively impacts the performance of adding comments and creating/editing issues - actions using user pickers or comment visibility.

Workflows

The following chart presents the response time of Jira actions in Jira 7.3 instances with 450 and 900 workflows.

Conclusion

The number of workflows has a noticeable impact on adding comments, with smaller effects on creating and viewing issues.

Permissions and Security Levels

The following chart presents response times of Jira actions in Jira 7.3 instances with 170 security levels and 200 permissions compared to 340 security levels and 400 permissions.

Conclusion

• The number of permissions has noticeable impact on the time needed to view a single board.
• No other significant changes to Jira performance have been observed.

Key takeaways

• Jira 7.3.0 was not a release solely focused on performance. We observed only slight performance improvements. We've expanded our performance testing pipeline to prevent any future regressions through closer monitoring of the results.
• Custom fields is the most impactful data dimension. It 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 number of comments, agile boards and attachments did not have a significant impact on Jira performance in our tests, and is not covered in detail here.

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. 

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