Infrastructure recommendations for enterprise Jira 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 and dataset sizes. Knowing your load and size profile is useful for planning your instance's growth, looking for inflated metrics, or simply keeping your instance at a reasonable size.

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

To help you out, we ran a series of performance tests on typical Large and XLarge Jira instances. We designed these tests to get useful, data-driven recommendations for your deployment's 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.

Performance results depend on many factors such as 3rd party apps, data, traffic, or instance type. Hence, the performance we achieved might not be replicable to your environment. Make sure you read through the methodology of our tests to learn the details of these recommendations.

For details on monitoring performance, see Jira Data Center sample deployment and monitoring strategy.



Executive summary

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 XLarge application nodes and database nodes:

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.

アプリケーションノード

データベース ノード

Apdex

1 時間あたりのコスト

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.

アプリケーションノード

データベース ノード

Apdex

1 時間あたりのコスト

c4.8xlarge x 3

m4.xlarge

0.737

4.97

Instance details: 

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.

アプリケーションノード

データベース ノード

Apdex

1 時間あたりのコスト

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.

アプリケーションノード

データベース ノード

Apdex

1 時間あたりのコスト

c5.4xlarge x 5

m4.4xlarge

0.723

4.20

Instance details: 



アプローチ

We ran all of our tests in AWS 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.

テスト手法

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.xlarge node for the database.

  • For XLarge, we used an m4.4xlarge node.

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 three c4.8xlarge and four c4.8xlarge. These application node configurations were the only ones that yielded Apdex above 0.70.

  • For XLarge, these were seven c5.9xlarge and five c5.4xlarge. These application node configurations yielded the highest Apdex.

To help ensure the reliability of our benchmarks, we tested each configuration four times. We ran the first and second test series on the latest enterprise release available to us at the time – Jira Data Center 7.13.

Data set in the Large instance tests

詳細を展開

We synthetically created the data set for Jira Data Center instance. This data set had the following dimensions:

メトリック

サイズのプロファイル

課題

1,000, 700

プロジェクト

1,500

ユーザー情報

100,000

カスタムフィールド

1,400

グループ

22,500

コメント

5,400, 000

XLarge

ワークフロー

2

権限スキーム

3

課題セキュリティ スキーム

17

Load profile in the Large instance tests

詳細を展開

We used 72 concurrent selenium browsers that undergo realistic user workflows at fast pace, to simulate the traffic of a Large client. This load is equivalent to 594,000 HTTP requests per hour.

Data set in the XLarge instance tests

詳細を展開

We synthetically created the data set for Jira Data Center instance. This data set had the following dimensions:

メトリック

サイズのプロファイル

課題

7,206, 140

XLarge

プロジェクト

3,001

XLarge

ユーザー情報

80,002

カスタムフィールド

1,513

グループ

6,525

Medium

コメント

55,089, 850

XLarge

ワークフロー

601

XLarge

権限スキーム

100

Medium

課題セキュリティ スキーム

4

Load profile in the XLarge instance tests

詳細を展開

We used 144 concurrent selenium browsers that undergo realistic user workflows at fast pace, to simulate the traffic of an XLarge client. This load is equivalent to 1,296,000 HTTP requests per hour.


ベンチマーク

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.

アーキテクチャ

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

Large instance XLarge instance


Configuration details for Jira Large

Configuration details for an L-sized instance

機能

Virtual machine type

注意

Jira アプリケーション

変数

The JVM heap was configured to 8G for all tests. Instance types used for the testing were: c5.2xlarge, c5.4xlarge, c4.8xlarge, c5.18xlarge

Each server had a 100GB General Purpose SSD (gp2) for the local storage. This has a baseline of 300 IOPS, burstable to 3,000 IOPS.

データベース

m4.xlarge

We used MySQL version 5.6.42 on an EC2 instance.

The instance size used for the database was m4.xlarge with 100GB General Purpose SSD (gp2). This has a baseline of 300 IOPS, burstable to 3,000 IOPS.

共有ホーム

変数

Our NFS server used a 100GB General Purpose SSD (gp2) for storage. This disk had an attached EBS volume with a baseline of 600 IOPS, burstable to 3,000 IOPS.

Instance size of the shared home was identical to the application size.

ELB Load balancer

1 x AWS Elastic Load Balancer


Refer to the AWS documentation on Instance Types (specifically, General Purpose Instances and Compute-Optimized Instances) for details on each virtual type we used in our tests.

Configuration details for Jira XLarge

Configuration details for an XLarge-sized instance

機能

Virtual machine type

注意

Jira アプリケーション

Variable:

c5.2xlarge

c4.8xlarge

c5.4xlarge

c5.9xlarge

c5.18xlarge

The JVM heap was configured to a maximum of 50GB for all tests. For c5.4xlarge, we set the maximum heap at 25GB.

Each server had a 300GB General Purpose SSD (gp2) for the local storage. This has a baseline of 300 IOPS, burstable to 3,000 IOPS.

データベース

m4.4xlarge

We used MySQL version 5.6.42 on an EC2 instance.

The instance size used for the database was m4.4xlarge with 300GB General Purpose SSD (gp2). This has a baseline of 300 IOPS, burstable to 3,000 IOPS.

共有ホーム

変数

Our NFS server used a 300GB General Purpose SSD (gp2) for storage. This disk had an attached EBS volume with a baseline of 300 IOPS, burstable to 3,000 IOPS.

Instance size of the shared home was identical to the application size.

ELB Load balancer

1 x AWS Elastic Load Balancer


Refer to the AWS documentation on Instance Types (specifically, General Purpose Instances and Compute-Optimized Instances) for details on each virtual type we used in our tests.


Test details: Large instance

Large test series 1: application nodes

Our first test series sought to find out which (and how many) AWS virtual machine types to use for the application node. For this series of tests, we benchmarked the following virtual machine types for the Jira application node:

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.18xlarge

We used a single m4.xlarge node for the database.

次のグラフは、各テストでの実際の Apdex ベンチマークを示しています。



These results show that the best performance came from c4.8xlarge nodes. You'll need at least three nodes for high availability, and the Apdex turned out the same for three and four nodes.

The hardware spec for this instance type, c4.8xlarge, is 36 CPUs and 60GB RAM. The tests using bigger hardware, c5.18xlarge, showed no performance improvements. Also, no performance improvements were observed by adding additional nodes.

In conclusion, for Large profile customers, we recommend c4.8xlarge 3 or 4 nodes, where 4 nodes are preferred for better fault tolerance.

See Amazon EC2 C4 Instances for more information about these nodes.

Source: Jira hardware exploration.

Large test series 2: database nodes

From the series of tests, we determined that when it came to the Jira application node, using c4.8xlarge 3 or 4 nodes provided the best Apdex results. Using this information, we moved on to testing this configuration against the database node.

Here, we benchmarked the following virtual machine types for the database node against both Jira application node configurations:

  • m4.large

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge

The database connection pool was configured to use the default 20 (minimum and maximum size).

The tests proved using m4.large resulted in a worse throughput than m4.xlarge. However, there are no changes to performance using a bigger database than m4.xlarge. This suggests that for the Large profile load, we should use m4.xlarge as the minimum database requirement that achieves the desired throughput.

Source: Jira hardware exploration.

Test details: XLarge instance

XLarge test series 1: application nodes

Our first test series sought to find out which (and how many) AWS virtual machine types to use for the application node. For this series of tests, we benchmarked the following virtual machine types for the Jira application node:

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.9xlarge
  • c5.18xlarge

We used a single m4.4xlarge node for the database. This was the smallest database to handle the XLarge data set.

次のグラフは、各テストでの実際の Apdex ベンチマークを示しています。


These results show that the best performance came from c5.9xlarge nodes. Based on these results, you need at least three nodes to provide an Apdex over 0.7. At three nodes, c5.9xlarge can also provide high availability for your cluster. Apdex turned out only slightly higher if you compare five and seven nodes (0.771 vs 0.774). However, at seven nodes the instance achieved notable throughput.

The hardware spec for this instance type, c5.9xlarge, is 36 CPUs and 72 GB RAM.


The Apdex for a smaller instance, c5.4xlarge reached 0.723 at five nodes and 0.766 at seven, which is only slightly worse than the results for c5.9xlarge nodes. Again, at least five nodes are required for HA. The hardware spec for c5.4xlarge is 16 CPUs and 32 GB RAM.


In conclusion, for XLarge profile customers, we recommend c5.9xlarge at a minimum of three nodes as a well-performing and high-available option. If cost is no issue, then c5.9xlarge at seven nodes produces the best performance results.

However, if cost-effectiveness is a concern, then c5.4xlarge at five nodes seems also to be a good option to consider.


See Amazon EC2 C5 Instances for more information about these nodes.

XLarge test series 2: database nodes

From the series of tests, we determined that when it came to the Jira application node, using c5.9xlarge 7 nodes provided the best Apdex results while 5 c5.4xlarge nodes proved to be the most cost-effective option. Using this information, we moved on to testing this configuration against the database node.

Here, we benchmarked the following virtual machine types for the database node against both Jira application node configurations:

  • m4.2xlarge

  • m4.4xlarge

  • m4.10xlarge

  • m4.16xlarge


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

アプリケーションノード

データベース ノード

Apdex

Cost per hour 1

c4.8xlarge x 4

m4.xlarge

0.734

6.56

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.

Recommendations for cost-effectiveness and optimal performance

アプリケーションノード

データベース ノード

Apdex

Cost per hour 1

c4.8xlarge x 3

m4.xlarge

0.737

4.97

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.


1 時間あたりのコスト

1 In our recommendations for the Large size profile, we quoted a cost per hour for each configuration. We provide this information help inform you about the comparative price of each configuration. This cost only calculates the price of the nodes used for the Jira application and database. It does not include the cost of using other components like shared home, or application load balancer.

These figures are in USD, and were correct as of April 2019.

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

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 also guarantees fault tolerance and notable throughput. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput. 

アプリケーションノード

データベース ノード

Apdex

Cost per hour 1

c5.9xlarge x 7

m4.4xlarge

0.774

11.51

Recommendations for cost-effectiveness

Interestingly, c5.4xlarge instance (16 CPUs and 31 GB RAM) at five nodes performed only slightly worse than c5.9xlarge at the same number of nodes 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.

アプリケーションノード

データベース ノード

Apdex

Cost per hour 1

c5.4xlarge x 5

m4.4xlarge

0.723

4.20

c5.9xlarge x 3 m4.4xlarge 0.71 5.39



1 時間あたりのコスト

1 In our recommendations for the Large size profile, we quoted a cost per hour for each configuration. We provide this information help inform you about the comparative price of each configuration. This cost only calculates the price of the nodes used for the Jira application and database. It does not include the cost of using other components like shared home, or application load balancer.

These figures are in USD, and were correct as of May 2019.


In-house examples

ユースケース

ノード

AWS application node

説明

Jira scale testing

2

c4.8xlarge

We use this environment to test loads comparable to Large-sized profile across different Jira versions. Each link on Scaling Jira shows a Jira version's response time to specific user actions compared to previous versions.

Public-facing Jira Service Desk instance (getsupport.atlassian.com)

3

c5.9xlarge

In Jira Data Center sample deployment and monitoring strategy, we describe two real-life Atlassian-managed Jira Data Center instances. Both are Large-sized instances hosting public-facing Atlassian services. They both feature identical architecture but use different application and database nodes.

Public-facing Jira Software instance

(jira.atlassian.com)

3

m4.4xlarge

Atlassian が提供するサービス

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.

最終更新日 2019 年 6 月 5 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.