Jira Data Center size profiles
Atlassian Technical Account Managers 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:
- Log in with the 'Jira Administrators' global permission.
Choose > System. Select Troubleshooting and Support > System Info to open the System Info page.
Write down the metrics for the following:
- Custom Fields
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)
- Choose > Issues.
- Select Permission Schemes to open the Permission Schemes page.
- Count the number of Permissions Schemes displayed here.
- Issue Security Schemes see Configuring issue-level security for more details.
- Choose > Issues.
- Select Issue Security Schemes to open the Issue Security Schemes page.
- Count the number of Issue Security Schemes displayed here.
Match metrics with size profiles
Consider that following values apply only to the environment with a database running on a different machine.
Use the following table to see which size profile your metrics fit into:
|Issues||up to 150,000||150,000 to 600,000||600,000 to 2,000,000|
|Projects||up to 200||200 to 800||800 to 2,500|
|Users||up to 1,000||1,000 to 10,000||10,000 to 100,000|
|Custom Fields||up to 250||250 to 800||800 to 1,800|
|Workflows||up to 80||80 to 200||200 to 600|
|Groups||up to 2,000||2,000 to 10,000||10,000 to 50,000|
|Comments||up to 250,000||250,000 to 1,000,000||1,000,000 to 4,000,000|
|Permission Schemes||up to 25||25 to 100||100 to 400|
|Issue Security Schemes||up to 50||50 to 200||200 to 800|
Any metric that registers above the Large range is XLarge - for example, over 2,000,000 Issues or over 2,500 Projects.
Custom Fields size profiles
The number of Custom Fields can greatly affect your instance's performance. Without proper governance, this number can grow beyond what your organization actually needs, unnecessarily straining your infrastructure.
The Custom Fields size profiles we created assume that an instance has the right number of Custom Fields. This means we also assume that admins took a disciplined approach to creating and managing them. For more information, see Managing custom fields in Jira effectively.
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:
Infrastructure recommendations for enterprise Jira 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.
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
- 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 Technical Account Manager (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.
Support team limitations
Support in general provide recommendations but again there is a limit to the amount (and depth) of assistance. There is a fine line between official best-practice and Professional Services-level Performance Tuning; which is beyond the scope of what Support can offer, something similar is mentioned in Support Offerings page:
Support Does Not Include:
- Professional Services
- System & Performance tuning
- Deployment & Capacity Planning
- Installation & Upgrade Services
What we offer is a high-level set of available options and observations which customer can implement based on their business demands