Cloud
Data Center 9.4
Versions

Jira Software guardrails

Performance and scaling

On this page

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

The content of this page applies to Jira 9.4. If you're looking for information about a different version, select it from the menu in the top-right corner.

Background

We’re committed to supporting the needs of our largest customers, and this includes continually improving the performance and scalability of our products. The amount of data in your instance can be a factor in performance and stability problems. As your instance grows, so does your risk of performance degradation over time. Often this is a gradual degradation and can go unnoticed until you reach a point where it has a significant impact on your team.

In the table below, we’ve described the performance and stability impacts that we’ve observed and suggested some actions you can take to reduce your risk. The guardrails are based on real-world experiences with some of our largest customers, but won’t necessarily be representative of every organization’s experience.

Ways you can reduce the risk of experiencing serious performance and stability problems may include:

  • application changes, such as upgrading to a newer application version to get the benefit of performance improvements, or changing the way users are managed.

  • infrastructure changes, such as increasing memory, CPU, or running a cluster or mirrors.

  • data cleanup activities to reduce your footprint, such as archiving or breaking up monolith sites.

It’s important to note that these aren’t hard limits, and some of your product instances may already exceed these thresholds. There are a number of factors, including the interplay between different data types, and site load, which will influence whether you experience the potential impacts listed below, and to what degree. As with any type of risk, it’s essential to identify the risk and make a plan, so you can prioritize those actions that will help you reduce the probability of future performance problems.

Definition

Product Guardrails are data type recommendations designed to help you identify potential risks and aid you making decisions about next steps in your instance optimization journey.

Jira Software guardrails

The following guardrails are provided to help you identify and mitigate scale risks, and make decisions about cleaning up your instance.

Projects

Content type

Number of active projects

Guardrail

7000 projects (not archived)

How to find this number

How to identify old projects to clean up

Risks

We've observed these problems when operating above this guardrail:

  • Number of projects makes permission calculation complex and therefore slower.

  • When creating a new project the application 'hangs' for 20-50 seconds per active node in the cluster (observed with 10k projects), and displays a timeout error after 60 seconds, even if the project is created successfully.

  • Reindexing takes a long time.

Mitigation options

Comments

Content type

Number of comments per issue

Guardrail

1000 comments per issue

How to find this number

How to find issues with the most comments in the database

Risks

We've observed these problems when operating above this guardrail:

  • Issue view loads slowly.

  • Out of memory errors, which can lead to application crashes (in extreme cases).

  • Reindexing takes a long time.

Mitigation options

  • Moderate a user group’s activity by setting a global limit on the number of specific items its members can create with Safeguards

  • Remove older comments via REST or using ScriptRunner.

  • Check any automation to make sure you're not adding unnecessary comments. Consider reducing the frequency or batching updates.

  • Implement rate limiting to prevent a misconfigured integration from adding thousands of comments in a short space of time. Learn about rate limiting

Attachments

Content type

Number of attachments per issue

Guardrail

3000 attachments per issue

10MB per single attachment

How to find this number

How to find issues with the most attachments in the database

Risks

We've observed these problems when operating above this guardrail:

  • Issue view loads slowly.

  • Load on shared home filesystem (for example, while loading of thumbnails)

  • Issue operations (such as view, update) or post-processing can trigger serialising the issue with all the issue properties, including all issue attachment properties.

Mitigation options

Content type

Number of issue links or sub-issues

Guardrail

1000 issue links

How to find this number

How to find issues with the most issue links in the database

Risks

We've observed these problems when operating above this guardrail:

  • Issue view loads slowly.

  • Can results in stuck threads, which can affect the whole instance.

Mitigation options

  • Identify issues with many issue links, and remove any unnecessary links

  • Archive issues that are no longer needed. Learn how to archive issues

Text

Content type

Amount of text in a field.

Guardrail

255 characters in single-line fields

100k characters in description and multi-line fields

How to find this number

Configuring advanced settings

Risks

We've observed these problems when operating above this guardrail:

  • Increased index size.

  • Slow search results.

Mitigation options

Custom fields

Content type

Total number of custom fields

Guardrail

1,200 custom fields

How to find this number

Analyze the usage of custom fields

Risks

We've observed these problems when operating above this guardrail:

  • Overall performance degradation.

  • Reindexing takes a long time.

Mitigation options

Epics

Content type

Number of epics

Guardrail

120,000 epics

How to find this number

You can use JQL to identify the number of epics, issuetype = Epic

Risks

We've observed these problems when operating above this guardrail:

  • Epic link menu loads slowly.

Mitigation options

Sprints

Content type

Total number of sprints

Guardrail

60,000 sprints

How to find this number

How to find the total number of sprints in the database

Risks

We've observed these problems when operating above this guardrail:

  • Overall performance degradation due to slow sprint cache population.

  • closedSprints() JQL function does not work (limited to 65,000 sprints).

Mitigation options

Workflow scheme bulk actions

Action

Associating a new issue type to an existing workflow scheme

Guardrail

1000 issues per bulk action

How to find this number


Risks

We've observed these problems when operating above this guardrail:

  • Bulk action can take a very long time to complete (several days)

  • Can’t view progress of a workflow scheme modification without shortening the URL

Mitigation options

  • Copy the original workflow scheme, make the change, then associate the workflow scheme project by project.

  • Do nothing. The background process will take a long time to complete, but it’s not resource-intensive and won’t cause performance issues. Make sure you don’t restart Jira until it has finished.

Change history

Content type

Number of changeitems or changegroups associated with an issue

Guardrail

20,000 changeitems or changegroups

How to find this number

Retrieve issue change history

Risks

We've observed these problems when operating above this guardrail:

  • Out of memory errors when viewing the History tab.

  • Issue view and other issue actions load slowly.

  • Reindexing takes a long time.

Mitigation options

  • Use a database query to identify issues with large changeitems and changegroups, then clone the issue, as the history is not copied to the new issue.

Users

Content type

Total number of users synchronized between LDAP and Jira

Guardrail

100,000 users

How to find this number

How to get the total number of users

Risks

We've observed these problems when operating above this guardrail:

  • Instance instability including outages and noticeable performance drops under heavy load
  • Increased time for directory synchronization and user authentication

Mitigation options

  • If most of the user accounts in your instance are stored in Crowd Data Center, Crowd Server, or Microsoft Active Directory, enable incremental synchronization. This way, only the changes since the last synchronization will be queried, reducing the need for a full sync. For more information, see Connecting to an LDAP directory.
  • Consider using Crowd Server and Data Center as your external user directory to take advantage of features such as access-based synchronization. For more information, see Syncing users based on their access rights
  • Use LDAP filters to reduce the number of users and groups to process by your instance. For more information, see:
    • Connecting to an LDAP directory
    • Reducing the number of users synchronized from LDAP to JIRA applications 
    • How to write LDAP search filters  
  • Become familiar with User management limitations and recommendations.

Inactive users

Content type

Number of inactive users with content assigned to them synchronized between LDAP and Jira

Guardrail100,000 users
How to find this numberHow to get the number of inactive users with content assigned to them 
Risks

We've observed these problems when operating above this guardrail:

  • Instance instability including outages and noticeable performance drops under heavy load
  • Increased time for directory synchronization and user authentication

Additionally, there is a known issue in Jira Server and Data Center 8.20.6 and older that results in increased directory synchronization and user authentication times if you have more than 10,000 inactive users with content assigned to them in your system.

Mitigation options
  • If possible, upgrade your Jira Server and Data Center instance to release 8.20.7 or newer. That release includes a fix for the performance degradation issue related to inactive users with assigned content.
  • If you can’t upgrade at this time, unassign the inactive users from Jira content, and then run a sync to remove inactive users from your directory. For more information, see Synchronizing data from external directories.

Groups

Content typeTotal number of groups synchronized between LDAP and Jira

Guardrail

25,000 groups
How to find this numberHow to get the total number of groups
Risks

We've observed these problems when operating above this guardrail:

  • Instance instability including outages and noticeable performance drops under heavy load
  • Increased time for directory synchronization and user authentication
  • Application access and group management UI unresponsiveness
Mitigation options
  • Configure your LDAP connection pool. Too many or too few connections may have a negative impact on performance. For more information, see Configuring LDAP connection pooling.

  • Disable group sync on every login by changing the Update group membership when logging in option to For newly added users only or Never. For more information, see Connecting to an LDAP directory.

    Changing this setting means that group membership data will not be updated until the next directory synchronization.

    Advances Settings section on the user directory configuration page in Jira

  • Become familiar with user management limitations and recommendations.


Depth of nested groups

Content type

Number of levels of hierarchy when groups are nested

Guardrail

4 levels deep

We also recommend groups do not contain a mix of users and other groups, as this can have a negative impact on performance.

How to find this numberHow to check the depth of group nesting
Risks

We've observed these problems when operating above this guardrail:

  • Instance instability including outages and noticeable performance drops under heavy load
  • Increased time for directory synchronization and user authentication
Mitigation options

Try rebuilding your group structure to prevent deep nesting. For example, you can split your group structure into two categories:

  • groups containing only user accounts (and not other groups)
  • groups containing only other groups (and not individual accounts)

Nested groups come with their own set of limitations and potential side effects. Make sure that you understand this mechanism before rebuilding your group structure. For more information, see Managing nested groups.

Show me an example...

For a better understanding of what this type of structure might look like, imagine the following simplified scenario, where an organization defines some high-level groups:

  • staff for all of the organization’s employees
  • engineering for members of the engineering department
  • design for members of the design department
  • marketing for members of the marketing department

In this example, we’ll focus on the engineering group. The group is part of the larger staff group and contains only smaller sub-groups representing separate Scrum teams (and not their members' accounts); for example dev-a and dev-b. The staff group does not store any user accounts itself, only the sub-groups for each department in the company.

By making sure that individual accounts are added only to the dev-a and dev-b sub-groups of engineering, you’ve reduced the level of nesting to a maximum of three while keeping an easy-to-maintain permission inheritance scheme.

The following tree diagram illustrates this hierarchy:

staff/
├─ engineering/
│  ├─ dev-a/
│  │  ├─ jsmith@acme.com
│  │  ├─ jdoe@acme.com
│  │  ├─ mdavis@acme.com
│  ├─ dev-b/
│  │  ├─ rlewis@acme.com
│  │  ├─ nphillips@acme.com
│  │  ├─ tadams@acme.com
├─ design/
├─ marketing/
Last modified on Mar 28, 2023

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.