Jira Data Center infrastructure recommendations

Still need help?

The Atlassian Community is here for you.

Ask the community

As your instance grows bigger in size, it may be time to consider an infrastructure upgrade. Planning this involves knowing how to deploy your application and database nodes. However, it's not always clear how to do that effectively – for example, adding more application nodes to a growing instance doesn't always improve performance (in fact, the opposite might happen).

To help you out, we ran a series of performance tests different sized instances of our products instances. We designed these tests to get useful, data-driven recommendations for the ideal size and number of application and database nodes. These recommendations can help you plan a suitable environment, or even check whether your current instance is adequate for the size of your content and traffic.



How do I use these recommendations?


Determine your instance size profile 




Start with establishing how big your instance is currently. It might be Small, Medium, Large, or XLarge. Have a look at our guidelines to find out:

Take a look at the recommendations


Once you know the size of your Data Center, review our hardware recommendations below and select the best option to fit your needs:

Monitor your instance for bottlenecks 



Keep monitoring your instance for spikes and bottlenecks. Browse our guidelines and see how we are monitoring our instances: 


What do I need to consider when reviewing these recommendations?

When reviewing our hardware recommendations, you need to consider the following:

  • Performance depends on a number of factors such as third-party apps, large repositories, data, traffic, concurrency, customizations, or instance type. Hence, the results we have achieved might not be fully replicable to your environment. We advise checking our test methodology to understand how the results were achieved. 
  • Note that the cost per hour that we provide does not include the cost of using other components of the application  like shared home  and application load balancer .
  • Dig in our test details to see what the throughput was for the recommended instance configuration. It might give you extra data to make an informed decision between the best-performing and the most cost-effective option. See Test details

How do I map these recommendations onto my instance?

  • Have a look at the specifications for the Virtual Machines types in the hardware we recommend and see how much CPU and Memory they have. Use this data as a baseline to plan your environment. Remember that anything you install on top of Jira, Confluence, or Bitbucket (like third-party apps) may influence performance and require more powerful or additional hardware.
  • The hardware for our performance tests were provisioned from Amazon Web Services (AWS). If your instance is deployed on a different platform, you can still use our recommendations as guidelines however the performance may vary slightly. 
  • Make sure you provision sufficient resources to the Atlassian applications you are running. If you are on virtual machines, make sure you have dedicated resources (vCPU and Memory) to run Jira, Confluence, or Bitbucket. We advise against over-provisioning or allocating shared resources to enterprise apps.

Recommendation summary

Recommendations for Jira Large

Recommendations for best performance and reliability - Jira L

For Large profile customers, we recommend c4.8xlarge 4 nodes, which guarantees best performance and fault tolerance. We also recommend m4.xlarge as the minimum database requirement that achieves the desired throughput.

Interestingly, c5.18xlarge instances (72 CPUs and 144 GB RAM) performed worse than c4.8xlarge. This behaviour was consistent throughout the tests.

Application nodes

Database node

Apdex

Cost per hour 

c4.8xlarge x 4

m4.xlarge

0.734

6.56

Instance details: 

Recommendations for cost-effectiveness and optimal performance - Jira L

The test results show that having powerful hardware with fewer nodes will provide the most optimal performance. The instance type used - c4.8xlarge - has 36 CPUs and 60 GB of RAM. Having 3 nodes of this type ensures good performance at a reasonable cost. We also recommend m4.xlarge as the minimum database requirement that achieves the desired throughput.

Application nodes

Database node

Apdex

Cost per hour 

c4.8xlarge x 3

m4.xlarge

0.737

4.97

Instance details: 

Recommendations for Jira XLarge

Recommendations for best performance - Jira XLarge

The test results show that having powerful hardware the most optimal performance. The instance type used - c5.9xlarge - has 36 CPUs and 72 GB of RAM. Hence, for XLarge profile customers for whom performance takes priority over cost, we recommend c5.9xlarge 7 nodes. This number of nodes guarantees best performance, throughput, and fault tolerance. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput.

Application nodes

Database node

Apdex

Cost per hour 

c5.9xlarge x 7

m4.4xlarge

0.774

11.51

Instance details: 

Recommendations for cost-effectiveness - Jira XLarge

Interestingly, c5.4xlarge instance (16 CPUs and 31 GB RAM) at five nodes performed only slightly worse than c5.9xlarge still reaching an Apdex higher than 0.70. This behaviour was consistent throughout the tests. Hence, for XLarge profile customers for whom cost effectiveness is key, we recommend c5.4xlarge 5 or 6 nodes, where 6 nodes are preferred for better fault tolerance. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput.

Application nodes

Database node

Apdex

Cost per hour 

c5.4xlarge x 5

m4.4xlarge

0.723

4.20

Instance details: 


Recommendations for Bitbucket Large

Recommendations for best performance - Bitbucket Large

We measured performance stability in terms of how far the instance’s average CPU utilization is from the 75% threshold. As mentioned, once we hit this threshold, git operations start to slow down. The further below the instance is from 75%, the less prone it is to slow due to sudden traffic spikes.

However, there are no disadvantages in using larger-size hardware (m5.12xlarge, for example), which will provide better performance.

Application nodes

Database node

NFS node

Cost per hour 

m5.4xlarge x 4

m5.2xlarge

m5.2xlarge

$4.168

Instance details: 

Recommendations for cost-effectiveness - Bitbucket Large

This low-cost configuration offered a lower Git throughput of 43,099 git hosting calls per hour than the optimal configuration. However, this is still above our minimum threshold of 32,700 git hosting calls per hour. The trade-off for the price is fault tolerance. If the instance loses one application node, CPU usage spikes to 85%, which is above our maximum threshold. The instance will survive, but performance will suffer.

Application nodes

Database node

NFS node

Cost per hour 

m5.4xlarge x 3

m5.xlarge

m5.xlarge

$2.840

Instance details: 

Recommendations for Bitbucket XLarge


Recommendations for best performance - Bitbucket XLarge

We measured performance stability in terms of how far the instance’s average CPU utilization is from the 75% threshold. As mentioned, once we hit this threshold, git operations start to slow down. The further below the instance is from 75%, the less prone it is to slow due to sudden traffic spikes.

Component

Recommendation

Application nodes

m5.12xlarge x 4

Database node

m5.2xlarge

NFS node

m5.2xlarge

Instance details:

m5.12xlarge = 48 vCPU and 192 GiB

m5.2xlarge = 8 vCPU and 32 GiB

Recommendations for cost-effectiveness - Bitbucket XLarge

This low-cost configuration offered a lower Git throughput of 74,458 git hosting calls per hour than the optimal configuration. However, this is still well above the defined threshold of 65,400 git hosting calls per hour. The trade-off for the price is fault tolerance. There were timeouts and errors observed on the m5.8xlarge x 3 nodes, so performance degradation may be encountered if an application node goes down.

Component

Recommendation

Application nodes

m5.8xlarge x 4

Database node

m5.2xlarge

NFS node

m5.xlarge

Instance details:

m5.8xlarge = 32 vCPU and 128 GiB

m5.2xlarge = 8 vCPU and 32 GiB

m5.xlarge = 4 vCPU and 16 GiB


Recommendations for Confluence Medium

Recommendations for best performance - Confluence Medium

The Performance option offers the best Apdex among all the configurations we tested. It can maintain an Apdex above 0.9 even when it loses one node. Confluence performed well in all tests, demonstrating Apdex of above 0.90.

RecommendationApplication nodesDatabase nodeCost per hour Apdex (6.13)

Performance

c5.xlarge x 2

m4.large

$0.522

0.929

Instance details: 

Recommendations for stability - Confluence Medium

The Stability option offers better fault tolerance at the same cost, but there is a slight drop in performance. Confluence performed well in all tests, demonstrating Apdex of above 0.90.

RecommendationApplication nodesDatabase nodeCost per hour Apdex (6.13)

Stability

c5.large x 4

m4.large

$0.522

0.905

Instance details: 

Recommendations for Confluence Large

Recommendations for performance - Confluence Large

The  Performance  option offered the best Apdex among all the configurations we tested. It can maintain an Apdex above 0.8 even when it loses one node.

RecommendationApplication nodesDatabase nodeCost per hour Apdex (per Confluence version)
6.136.14
Performancec5.4xlarge x 2m4.2xlarge2.090.8520.874

Instance details: 

Recommendations for stability and cost-effectiveness - Confluence Large

The Stability and Low cost options offer a good balance between price, fault tolerance, and performance. You'll notice that they both use the same virtual machine types – the Stability option just has an additional application node. The Stability option can afford to lose more nodes before going completely offline, but the Low cost option costs less. Any performance difference between the two is negligible. 

RecommendationApplication nodesDatabase nodeCost per hour Apdex (per Confluence version)
6.136.14
Stabilityc5.2xlarge x 4m4.xlarge1.720.8170.837
Low costc5.2xlarge x 3m4.xlarge1.380.8200.834

Instance details: 

Recommendations for Confluence XLarge

Recommendations for stability - Confluence XLarge

The  Stability  configuration can maintain acceptable performance (that is, Apdex above 0.8) even if it lost one application node. At four application nodes, it is more fault tolerant overall than the  Low cost  configuration.

ConfigurationApplication nodesDatabase nodeCost per hourApdex (per Confluence version)
6.136.15
Stabilityc5.4xlarge x 4m4.2xlarge3.450.8100.826

Instance details: 

Recommendations for cost-effectiveness - Confluence XLarge

The  Low cost  configuration is fairly fault-tolerant, in that  it can afford to lose 3 nodes  before the service goes offline. However, our tests show that if the  Low cost  configuration loses one node, the Apdex dips below 0.8.

ConfigurationApplication nodesDatabase nodeCost per hourApdex (per Confluence version)
6.136.15
Low costc5.4xlarge x 3m4.2xlarge2.770.8110.825

Instance details: 


Test details

Reviewing test data might give you more insights about how we performed out tests and what we measured.

Last modified on Jul 1, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.