Jira, Confluence and BitBucket on AWS

[Jay Kantaria]

Hi All,

Task is to setup Atlassian tools in AWS.  These are stand alone tools (not the data center).  I am leaning toward MySQL instance that will be shared among all of these tools in their own DB.   This is only for demo version of 30 users only.

- What type of EC2 to use for Jira, Confluence, and BitBucket?

- Is shared MySQL instance on AWS RDS service  a right way? Is there size recommendation?

- Are there any templates available?

- We need this in on RHEL due to security requirements.

Any help will be appreciated.

JK

[Craig Castle-Mead · Accepted solution]

I’d suggest Postgres - it’s the most supported of the supported databases (what Atlassian develop against). Single RDS instance with multiple databases is fine

EC2 size - something like an M4 or M5.xlarge  per application might be enough, but depends on how hard you’ll be testing.

CCM

[Andy Heinzer]

I'd also like to add that you might want to look into the Jira Sizing Guide.  This provides a listing of hardware expectations based on the size of your Jira environment.  If you have lots of users, issues, custom fields, and/or plugins, you will likely need more resources to keep Jira running smoothly.   This guide though can be a good baseline just for running Jira alone.

[Tim Theis]

I'm interested in learning how you finalized the analysis of your configuration.

I'm also evaluating a stand alone install to AWS (not Datacenter)... we are on the fringe of a large/enterprise grade instance per the sizing guide. We tested on an m4.2xlarge with a co-hosted PostgreSQL DB on the same EC2.

Performance is not great, however there is no degradation even with a 200 concurrent user load test and resources are only maxing out at around 25% utilization. The seems to point to an oversized EC2, but still not achieving the desired performance results.

3,500+ users with 2-300 concurrent
360+ Projects; 190K+ Issues; 125 workflows, 700+ custom fields
4 GB DB
1 TB files

[Craig Castle-Mead]

Hey Tim,

It would be interesting to know what your definition/expectation of performance would be in something that's tangible+measurable - ideally in the ranges of:

1. Perfect
2. Yeah, fine - don't really think it's slow or fast
3. Not great, but I can deal
4. I'm going to flip tables if this doesn't improve

Having a common baseline for measuring performance (where are your users coming from, what's the latency just to get from them to the server, do they have crappy connections)

The above information is likely going to be very valuable as you move forward to understand if it's users with unrealistic expectations, even your problem (is it upstream network) or if it is actually something you can do on the infrastructure side to improve.

On our Jira install running on a m5.4xlarge (Ubuntu 16.04), we have:

• 13,500 licensed users ~ 2000 uniques/day
• 9500 projects
• ~ 1M issues
• mysql running locally
• 630 workflows
• 1350 custom fields
• ~ 40 add-ons
• We leverage CloudFront to offload as much of the unnecessary workload as possible (https://community.atlassian.com/t5/Jira-discussions/CDN-CloudFront-and-Atlassian-Server-apps/td-p/731230  for a writeup)
• There's also an ELB handing SSL offloading > nginx (has some custom rules in it to help minimize unnecessary traffic) > jira apps

We're absolutely pushing the limits of a single node with these numbers (and have an active project to move to DC) - and has taken a lot of tuning to even get it to be able to handle this amount of traffic.

While there's no flat answer, I feel it's likely that an m4.2xlarge would be a good starting point to your sizing, but always monitor and adjust as needed. Depending on where your AWS region of choice is, if m5 instances are available, start with that - they're cheaper for more compute, and while it is possible to resize from m4's to m5's, the network driver changes as do the EBS device IDs and I've only had ~ 50% success rate in resizing and things "just working".

A lot of the journey for us has been making changes based off recommendations / best practices etc, but having no repeatable/reliable measure of knowing the direct impact. If performance has seemingly improved, do we just have a different user profile? Even with standard load testing tools, they should be more reliable, but you still need to configure the traffic. https://atlasauthority.com/atlas-load/ is by one of the Atlassian Partner that records actual production traffic that can then be played back on a copy of the environment so you can quantify changes in the real world - might be worth looking at.

CCM