As any homeowner could tell you, the physical components of a house don’t last forever – it’s only a matter of time before you’ll need a new roof. Further complicating the matter is the fact that new technologies, from home security systems to eco-friendly energy options, are constantly emerging. So the same way new buyers agonize over which dishwasher to install, seasoned owners must continually re-evaluate these components to determine when it’s time to make an upgrade.
Organizations face similar decisions when choosing an infrastructure for deploying their software. Many of our customers struggle with this choice, not only when they’re upgrading from Server to Data Center, but also as a part of the ongoing management of their Data Center instance. It’s not a trivial task, no matter the size of your organization, and many users wonder whether they need to purchase new components or if they can make do with their existing infrastructure.
Here are a few examples of some questions we commonly hear:
- “Is it true that we shouldn’t have more than four nodes in a cluster? Why?”
- “How can we determine which resource we should increase (CPU, memory, nodes, etc)?”
- “I have X amount of data and X traffic – how many nodes do I need?”
To help organizations plan their infrastructure setup and growth, we ran a series of performance tests on a variety of instance types for Jira Software, Confluence, and Bitbucket. These tests were designed to provide useful, data-driven recommendations for deployment applications and database nodes.
How to find the right infrastructure for your organization
Identify your instance size
Last year, we published load profiles to help you better understand the size of your instance and plan your instance’s growth, find inflated metrics, or simply keep your instance at a reasonable size.
Understanding your load profile is also an important factor in determining your infrastructure, but not only at the time of your initial deployment; you might find that as you grow, an infrastructure upgrade is needed to maintain stability and performance. Oftentimes, adding more nodes isn’t the solution to improving performance, and sometimes even smaller optimizations to your instance aren’t the answer. At certain points in your journey, your hardware configuration might be the culprit.
Use the following tables to identify your load profile:
Decide what matters most
Now that you understand your load profile, or the instance size of your product, you should determine what matters most to your organization. In each of our tests, we measured different hardware configurations against two or more of the following variables: cost, stability, and performance. Performance is based on the best Apdex score no matter the cost, while stability is measured according to fault tolerance. Cost indicates the cheapest solution that still provides a satisfying level of performance. As a part of the hardware selection process, it is important for you and your team to understand which of these variables you value most.
Research our approach
All of our tests were conducted on a variety of AWS compute-optimized and general-purpose instances where the only variable was hardware – the configuration of application and database nodes. Other dimensions remained unchanged, including product version, data set, and traffic. This approach guaranteed that our recommendations were solely focused on how hardware impacted cost, stability, and performance.
For those of you who don’t use AWS, these results can still serve as a reference point. You can check the actual hardware used and compare that to the options available to you if you deploy using another cloud provider, like Microsoft Azure, or on bare metal.
Note: The testing environment didn’t include any apps or custom integrations with a consistent peak load, which is likely not the case for your production instance.
Use our results as a reference
Next, you’ll use these results to choose the right infrastructure. Each organization has a different setup – different data sets, apps, traffic, configurations, and other variables that may impact your decision – but the results we’ve published give a point of reference and help you understand how hardware requirements may change as you continue to grow.
For example, consider our results for a large data set in Confluence. As you can see below, fewer, more powerful nodes resulted in the best performance but less resilience, while a larger number of smaller nodes resulted in relatively strong performance (not the best), and was less expensive and more resilient.
Note: These results should only be used as a reference. Apdex scores may not be possible to achieve, depending on your environment and other factors.
Want to learn more about our methodology or approach? Dive into our documentation to ensure you’re making smart decisions from the get-go and choosing the hardware your organization needs.