Jira Sizing Guide

Atlassian Advisory Services and support engineers can better tailor their configuration and environment recommendations when they know the overall size of your instance. This information also helps you estimate your instance's growth, allowing you to prepare for it.

To help you estimate your instance's size, we narrowed down which metrics were most useful in doing so. Next, we created a set of profiles (or size tiers) for those metrics, ranging from Small to XLarge. We based each metric's profiles on a wide range of  Server and Data Center customer case studies, covering instances of varying infrastructure sizes and configurations. In the future, we hope to also use these profiles in our own infrastructure and hardware recommendations.

Your instance could fall under different profiles for each metric. For example, your number of issues could be XLarge with everything else at Medium or below. We'll help you figure out the overall size of your instance!

How to collect the metrics

You can collect all but two of the metrics Jira's System Info page:

1. Log in with the 'Jira Administrators' global permission.

2. Choose > System. Select Troubleshooting and Support > System Info to open the System Info page.

3. Write down the metrics for the following:

   • Issues
   • Projects
   • Users
   • Custom Fields
   • Workflows
   • Groups 
   • Comments

You'll also need to note the following metrics, which are available from the Issues page:

• Permission Schemes (see Managing project permissions for more details)
  1. Choose  > Issues.
  2. Select Permission Schemes to open the Permission Schemes page.
  3. Count the number of Permissions Schemes displayed here.
• Issue Security Schemes  see Configuring issue-level security for more details.
  1. Choose  > Issues.
  2. Select Issue Security Schemes to open the Issue Security Schemes page.
  3. Count the number of Issue Security Schemes displayed here.

Match metrics with size profiles

Use the following table to see which size profile your metrics fit into:

Any metric that registers above the Large range is XLarge - for example, over 2,000,000 Issues or over 2,500 Projects.  

Determine your overall size profile

The overall size profile of your instance is generally dictated by the highest registered size profile of any metric you collected earlier. So if any single metric registers at Large, then we believe that it's safe to declare your instance's overall size profile as Large. 

From the many customer instances we studied, the size profiles we use were good indicators of an instance's overall size. Our data suggests that when your instance's overall size profile increases, the increase in load could warrant changes to the instance or its infrastructure.

How to use this information

Track these metrics to see how fast your instance's overall size grows. Find out the growth rate of each metric by comparing data snapshots over time. Then, compare these rates to each metric's size profiles to get a sense of when your instance is about to outgrow its overall size profile. Stepping up into the next content or traffic profile usually means it's time to evaluate your current infrastructure, and decide how you'll scale to meet the increased load.

Staying ahead of hardware requirements

Once you figure out how fast your instance grows, plan ahead! The following resources will help you understand the hardware needs of different instance sizes:

• Jira Data Center: Infrastructure recommendations for enterprise instances on AWS: this page provides recommendations for deploying appropriate infrastructure on for Large and XLarge instances. It also explains the methodology and results of the tests that form the basis of those recommendations.

• Jira applications installation requirements: this page shares some basic per-node hardware guidelines for different production scenarios (specifically, see Server-side installation requirements for production).
• Node sizing in a clustered Jira environment: this page offers general recommendations for node sizing, memory allocation, as well as the CPU requirements for nodes.
• Scaling Jira: here, we link to several pages covering how each Jira version performs against a specific data set. Each page contains information about that version's test environment, which includes details on node hardware.
  
• Jira Data Center sample deployment and monitoring strategy: this page describes the architecture, configuration, and hardware we use for two of our Large-sized, public-facing Jira instances. 

Handling bloat

In some cases, a single metric could be defining your overall size profile – for example, you can have a Large number of Issues, with all other metrics being Small. This bloated metric affects performance; once identified, you can find ways to manage it. For example, archiving can address a bloated number of projects and issues (see Moving or archiving individual projects) while better housekeeping can help prevent Custom Field bloat (see Managing custom fields in Jira effectively).

Keeping your instance size in check

We generally recommend you keep your instance size in check whenever possible. You should also focus on keeping the following metrics down to Medium whenever possible:

• Custom Fields
• Workflows
• Permission Schemes
• Issue Security Levels

Growing these metrics to Large and up could generate load that requires significant infrastructure changes. It's much cheaper to control their size profile; plus, we generally find that there's little reason to grow them beyond Small, even for large and complex organizations. 

Help us help you

If you need to open a ticket, share your instance's overall size profile with your Advisory Services (if you have one) or support engineer. This information can help us assist you better.

You can also go a step further by sending us analytics data about your instance. This data allows us to study the user experience across thousands of users, helping us deliver features and improvements that matter. It also helps us create average profiles (like the ones on this page) that we can use to provide better configuration and infrastructure recommendations. 

If your instance doesn't currently send analytics data to us, check out our Data Collection Policy to learn out what we collect, how it's sent to us, and how you can opt-in.