Infrastructure recommendations for Enterprise Jira Service Management instances on AWS

In Jira Data Center size profiles, we presented simple guidelines for finding out if your instance was Small, Medium, Large, or XLarge. We based these size profiles on different Server and Data Center case studies, covering instances of varying infrastructure sizes and configurations. Knowing your load profile is useful for planning for your company's growth, looking for inflated metrics, or simply reviewing your infrastructure's suitability.

Summary of recommendations

Based on the analysis of the benchmarks and configurations from the tests we’ve run, we came up with the following cost-effective and fault-tolerant recommendations for Jira Large and Jira XL application nodes and database nodes.

Read more about our testing methodology.

Recommendations for best performance and reliability - Jira L

For Large profile customers, we recommend c4.8xlarge 3 nodes for Jira 8.5, which guarantees best performance and fault tolerance. The test results show that having powerful hardware with fewer nodes will provide the most optimal performance.

For Jira 8.13, we recommend c5.9xlarge 3 nodes, which guarantees best performance and fault tolerance. The test results show that having relatively powerful hardware with fewer nodes will provide the most optimal performance.

We also recommend m4.2xlarge (8.13) or  m4.4xlarge (8.5) as the minimum database requirement that achieves the desired throughput. 

Instance details:

• m4.2xlarge = 8 vCPU and 32 GiB RAM
• c4.8xlarge = 36 vCPU and 60 GiB RAM
• c5.9xlarge = 36 vCPU and 72 GiB RAM
• m4.4xlarge = 16 vCPU and 64 GiB RAM

Recommendations for cost-effectiveness and optimal performance - Jira L

For Jira 8.5, 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 two or three 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. 

For Jira 8.13, the test results show that less powerful hardware provides optimal performance at low cost. The instance type used -  c5.2xlarge - has 8 CPUs and 16 GB of RAM. Having 3 or 4 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.

Instance details: 

• c4.8xlarge = 36 vCPU and 60 GiB RAM
• c5.2xlarge = 8 vCPU and 16 GiB RAM
• m4.xlarge = 4 vCPU and 16 GiB RAM
  

Recommendations for best performance and reliability - Jira XLarge

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

For Jira 8.13, we recommend c5.4xlarge 2 nodes. This number of nodes guarantees best performance, throughput, and fault tolerance. The instance type used (c5.4xlarge) has 16 CPUs and 32 GB of RAM. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput.

Instance details: 

• m4.4xlarge = 16 vCPU and 64 GiB RAM
• c5.9xlarge = 36 vCPU and 72 GiB RAM
• c5.4xlarge = 16 vCPU and 32 GiB RAM
  
  

Recommendations for cost-effectiveness and optimal performance - Jira XLarge

Interestingly, for Jira 8.13, c5.2xlarge instance 8 CPUs and 16 GB RAM) at 3 nodes performed only slightly worse than c5.4xlarge 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.2xlarge 3 or 4 nodes, where 4 nodes are preferred for better fault tolerance. 

This behavior could also be observed for Jira 8.5, where c5.4xlarge performed nicely in terms of the Apdex and throughput. This is why, if you're considering Jira 8.5, we recommend c5.4xlarge 6 or 7 nodes, where 7 nodes are preferred for better fault tolerance. However, it's worth noting that c5.9xlarge achieved a similar Apdex at 3 nodes, which is only slightly more expensive than the c5.4xlarge.

We recommend m4.xlarge as the minimum database requirement that achieves the desired throughput for Jira 8.5 and Jira 8.13.

Instance details: 

• m4.xlarge = 4 vCPU and 16 GiB RAM
• c5.4xlarge = 16 vCPU and 32 GiB RAM
• c5.2xlarge = 8 vCPU and 16 GiB RAM
  
  

Approach

We ran all of our tests in AWS (Amazon Web Services) environments. This allowed us to easily define and automate many tests, giving us a large and reliable sample of test results.

Each part of our test infrastructure is a standard AWS component available to all AWS users. This means you can easily deploy our recommended configurations. You can use AWS Quick Starts for deploying Jira Data Center to do so.

Since we used standard AWS components, you can look up their specifications in the AWS documentation. This lets you find equivalent components and configurations if you prefer to use a different cloud platform or bespoke clustered solution.

Considerations

We gathered a large sample of benchmarks for analysis and we designed tests that could be easily set up and replicated. As such, when referencing our benchmarks and recommendations for your infrastructure plans, consider the following:

• We didn't install apps on our test instances, as our focus was finding the right configurations for the core product. When designing your infrastructure, you need to account for the performance impact of any apps you want to install.

• For the Large test, we used MySQL 5.6.42 with the default settings, except for the maximum number of connections, which was increased to 151 connections.For the XLarge test, we also increased the buffer pool to 40 G and the log file size to 2GB.

• Our test environment used a dedicated AWS infrastructure hosted on the same subnet. This helped minimize network latency.

Methodology

Each test run involved applying the same amount of traffic to the same Jira data set, but on a different AWS environment. We ran two series of tests: one to determine optimal configurations for the Jira application node, and the other for the database node.

Test series 1: Our first test series sought to find out which (and how many) AWS virtual machine types to use for the application node.

• For the tests on the Large instance, we used a single m4.2xlarge, m4.4xlarge, and m4.xlarge node for the database depending on the Jira version. 

• For XLarge, we used an m4.4xlarge/m4.xlarge node for the database depending on the Jira version.

Test series 2: Our second test series benchmarked different virtual machine types for the database. Here, we tested different virtual machine types against the two application node configurations that proved best-performing in Test series 1.

• For L, these were two and three c4.8xlarge for Jira 8.5 and three c5.2xlarge and c5.9xlarge for Jira 8.13.

• For XLarge 8.13, these were three c5.2xlarge and two c5.4xlarge. These application node configurations yielded the highest Apdex. For XLarge 8.5, these were six c5.9xlarge.

To help ensure the reliability of our benchmarks, we tested each configuration two times. We ran the first and second test series on two Long Term Support releases available to us at the time – Jira Data Center 8.13 and Jira Data Center 8.5.

Data set in the Large instance tests

Load profile in the Large instance tests

Data set in the XLarge instance tests

Load profile in the XLarge instance tests

Benchmark

For each test run, we used an Apdex of 0.7 as our threshold for acceptable performance. This Apdex assumes that a 1-second response time is our Tolerating threshold, while anything above 4 seconds is our Frustrated threshold.

Note that the Apdex represented here may not directly match what might be observed in production. The testing environment didn’t have any apps or custom integrations with a consistent peak load, which may be different from your running production instance.

Architecture

We tested each configuration on a freshly-deployed instance of Jira Data Center on AWS.

Configuration details for Jira Large

Configuration details for Jira XLarge

Test details: Large instance

Test details: XLarge instance

Recommendations for Large Jira instance

We analyzed the benchmarks and configurations from our Large testing phase and came up with the following recommendations that in our opinion are the most cost-effective and fault-tolerant.

For details behind these recommendations see the Large test phase: application nodes and Large test phase: database nodes sections above.

Recommendations for best performance and reliability

Interestingly, c5.18xlarge instances (72 CPUs and 144 GB RAM) performed worse than c4.8xlarge for Jira 8.5 and than c5.9xlarge for Jira 8.13. This behaviour was consistent throughout the tests. For Large profile customers, we recommend c5.9xlarge 3 nodes for Jira 8.13 and c4.8xlarge 3 nodes for 8.5, which guarantees best performance and fault tolerance. We also recommend m4.2xlarge as the minimum database requirement that achieves the desired throughput for Jira 8.13 and for Jira 8.5 this is m4.4xlarge.

Recommendations for cost-effectiveness and optimal performance

For Jira 8.5, 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 2 or 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.

For Jira 8.13, the test results show that less powerful hardware provides optimal performance at low cost. The instance type used -  c5.2xlarge - has 8 CPUs and 16 GB of RAM. Having 3 or 4 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.

Recommendation for XLarge Jira instance

We analyzed the benchmarks and configurations from our XLarge testing phase and came up with the following recommendations that in our opinion are the most cost-effective and fault-tolerant.

For details behind these recommendations see the XLarge test phase: application nodes and XLarge test phase: database nodes sections above.

Recommendations for best performance and reliability

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 6 nodes for Jira 8.5. This number of nodes also guarantees fault tolerance and notable throughput. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput. 

For Jira 8.13, we recommend c5.4xlarge 2 nodes. This number of nodes also guarantees fault tolerance and notable throughput. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput. The instance used - c5.4xlarge, is 16 CPUs and 32 GB RAM.

Recommendations for cost-effectiveness and optimal performance

Interestingly, for Jira 8.13, c5.2xlarge instance (8 CPUs and 16 GB RAM) at three nodes performed only slightly worse than c5.4xlarge at two nodes still reaching an Apdex higher than 0.70. This behaviour was consistent throughout the tests. Hence, for Jira 8.13 XLarge profile customers for whom cost effectiveness is key, we recommend c5.2xlarge 3 or 4 nodes, where 4 nodes are preferred for better fault tolerance.

For Jira 8.5, where c5.4xlarge performed nicely at six nodes. This is why, if you're considering Jira 8.5, we recommend c5.4xlarge 6 or 7 nodes, where 7 nodes are preferred for better fault tolerance. However, it's worth noting that c5.9xlarge achieved an Apdex higher than 0.70 at 3 nodes, and this solution is only slightly more expensive than the c5.4xlarge at 6 nodes.

We recommend m4.xlarge as the minimum database requirement that achieves the desired throughput for Jira 8.13 and Jira 8.5.

Instances we use at Atlassian

The table below shows some in-house production instance, which you can refer to.

We're here to help

Over time, we may change our recommendations depending on new tests, insights, or improvements in Jira Data Center. Follow this page in case that happens. Contact an Atlassian Technical Account Manager for more guidance on choosing the right configuration for your Data Center instance.

Our Premier Support team performs health checks by meticulously analyzing your application and logs, to ensure that your infrastructure configuration is suitable for your Data Center application. If the health check process reveals any performance gaps, Premier Support will recommend possible changes.