Haut de page

[Interview] Beyond Performance at Scale: Valiantys’ take on Jira Data Center


Posted by
Stefanie Chernow

June 26, 2018

As a follow-up to Valiantys’ Can Jira Handle 10 million issues? reportValiantys and Atlassian jointly published a guide that advances that initial study to address our clients who are concerned with scaling their Jira instances.

For many Jira admins, the adoption of a single Jira instance goes viral throughout the company until it becomes a mission critical tool. However, without enough foresight and planning, admins may find themselves in a difficult situation if there is no governance to manage Jira’s growth. Admins might feel like they are losing control over the application’s stability and performance, without a clear vision of what is causing Jira to reach its tipping point.

Performance at Scale: 10 million issues and beyond with Jira Data Center, looks at the root causes that result in Jira reaching its tipping point. This includes hardware limits, concurrent users, data complexity, the frequency of updates, and integrations and indexing. These factors may vary for different enterprises, meaning there is no silver bullet response of how to best scale. Governance, intensive functional and performance testing are needed to ensure you’re getting the optimal results on your Atlassian investment.

At Valiantys, our experience as an Atlassian Platinum Solution Partner has given us the technical experience needed to accompany organizations as they decide to make the switch to Data Center. Lucas Dussurget, Valiantys’ VP and author of Can Jira Handle 10 million issues?, and I discussed the challenges of scalability and how to overcome the pain-points.


Stefanie Chernow: What is the most common problem we see at Valiantys when we’re working with customers who want to switch to Data Center? 

Lucas Dussurget: I think the problem is a lot of clients are too reactive. They need to be more proactive. Redoing your architecture and moving to Data Center is not something that happens overnight. Yet once you realize you have performance and stability problems because you didn’t scale soon enough, you start to go into fight or flight mode and you rush things.

Instead, you should anticipate where the breaking points might be for you. Are you reaching the limits of your hardware, or can you use that as a leverage? Are the increasing concurrent users going to be an issue, or is your instance stable on that front?

Let’s look at an example concerning data volume in Jira. Maybe you only have 800,000 tickets and everything is running smoothly. But how many tickets are you creating per month? If it is 55,000 tickets, that means in four months you’ll be at one million tickets. In a year you’ll be at nearly 1.5 million tickets, but that’s only if you keep creating at the same rate. If your rate is increasing by 5% every month, in a year’s time you’ll actually be around 1.7 million tickets. If you think you’ll be able to support that volume of data in a standard server deployment without architecture changes, think again.

Ideally, you should always try to have a one year outlook on your applications. You should know if what you have today will cover you for the next twelve months, or have a plan in place if it doesn’t. The process which includes a proof of concept deployment (PoC), building a business case, procuring licenses, building the infrastructure, carrying out the deployment and migration takes time, so you’ll want to get an early start.

How can enterprise organizations best prepare themselves for scalability? 

All the analysis, forecasting and planning only happens when there is a proper system of governance for the Jira instance. If you don’t have a system of governance, then no one is going to ask themselves ‘Are we OK to scale?’ until it’s too late. Having a governance framework in place is going to help you define rules on what can and can not be done in Jira.

In Performance at Scale: 10 million issues and beyond with Jira Data Center, within the data complexity section we see a scenario with nearly 4,000 custom fields, 1,200 workflows, 400 permission schemes, 350 levels of security, etc. This entire scenario is extreme and we should never see an instance come to that level of complexity. Even if you have thousands of users, it is hard to justify 1,600 workflows. Are there really 1,600 ways of doing work in your company? These are the type of questions you should ask, and that’s the sort of thing you do with governance.

Good governance is about preventing undue complexity while offering an element of flexibility. It’s about finding the right balance between standardization and customization. You need someone that can appreciate the pros and cons in adding complexity and volume to Jira, educate users and consider their requests. Having these roles and processes defined within the company will ensure the application is well-run.

Even after the leap to Data Center, where you are using several nodes instead of just one, how important is it to reign in unmanaged growth?

There are limits to how much you can scale. I don’t believe that today you can scale to 25 million tickets and just add 25 nodes to your cluster. From our testing, we’ve found the optimal performance point is around 5 to 6 nodes. After that point it appears to plateau, and in fact  you start to get diminishing returns because the effort Jira produces from replicating data across the nodes becomes so large it counteracts the benefits of having more processing power.

Again, this is why having governance in place is important, and Valiantys can help you build the right architecture for your needs.

How can enterprises customers be certain that Atlassian’s Data Center will deliver on its promises? 

Whether the customer anticipated growth or they’ve found themselves in a crisis situation, customers often reached out to us for a PoC in order to quickly validate this solution is viable for them. Every client is unique, so you’ll see instances that are set up very differently. Sometimes you’ll see volume that is high, but complexity that is low. For other clients it’s the opposite, for example when many different Marketplace apps are integrated into Jira.

If a client wants to do performance testing, we’ll simulate the configuration that we have today or the configuration that we forecast. Can it be handled by the current architecture? Or should a node be added?

What’s useful about the PoC is it is not just about setting it up to see if it works, but it is about simulating conditions as close to real life as possible along with experimenting with different conditions, capturing the results and analyzing whether they are acceptable. We want to simulate this for our clients because Jira is an investment and you should be sure it is viable.

In Performance at Scale: 10 million issues and beyond with Jira Data Center, the report detailed running a PoC for each root cause that could overload the instance. What is the added value of a Platinum Solution Partner like Valiantys accompanying clients with their PoC?

We’ve Jira performance tuning for several 500 Fortune companies and have more than ten years of expertise in this domain. Our Atlassian certified consultants come equipped with performance testing scripts we’ve already built. They are well-versed in setting up the environments, which could be quite complex for a customer to do themselves. As we’ve done PoCs with other customers, we can compare your results to others we’ve previously run, giving us an idea of what we should expect. Valiantys can come in and run a PoC quite smoothly, ensuring your company doesn’t waste time or resources.

Download Performance at Scale: 10 million issues and beyond with Jira Data Center

There’s no time like the present to start thinking about scalability. Download the joint report by Atlassian and Valiantys to learn the factors which will drive your instance from a Server to a Data Center deployment. If you need help with your PoC, don’t hesitate to leave us a message below the line.