Revving Up Jira: Proven Techniques for Improved Performance and Efficiency

• “I feel like I’m constantly waiting for Jira to load or update.”
• “Our team has been struggling with Sprint planning due to Jira’s slow performance.”
• “Jira is extremely laggy and whole system is slow.”
• “I can’t even get the dashboard to load, let alone work on my tasks.”
• “Our team has lost productivity because of Jira’s slow response times.”

If your organization is a loyal Jira user for agile software development at a large enterprise company like Intuit, read on.

We’ve come up with a practical solution for overcoming common performance issues that can impact user productivity and satisfaction for any company that relies on Jira to manage projects or track issues efficiently.

As a global financial technology platform company serving more than 100M consumer and small business customers around the world with TurboTax, Credit Karma, QuickBooks, and Mailchimp, accelerating development velocity is a top priority for Intuit.

So when we noticed that the complexity and size of our Jira setup, and heavy customization, was leading to performance bottlenecks, in 2022 we set out to solve it as a “mission team” within the Developer Experiences (DevX) organization with fantastic support from Atlassian. Within a matter of months we completed the optimization to dramatically rev up Jira at Intuit.

Today, our Jira instance (Jira Data Center) is running on AWS, serving as a centralized hub for 3,000 projects, 6 million records, 400 webhooks, fewer than 500 custom fields, and hundreds of workflows. As you can imagine, managing such a large and complex Jira instance requires careful planning and solid strategy to ensure smooth performance and awesome user experiences.

In this blog, we’ll share our approach to:

• Identifying a bottleneck in Jira performance
• Determining the root cause(s)
• Implementing solutions to optimize performance

Even if your organization isn’t experiencing these issues yet, our hope is that following these steps will contribute to your ability to your success in scaling with Jira in the future as your company grows.

Know your bottlenecks

At Intuit, our approach to problem solving, internally and externally, begins with cultivating a deep understanding of user experiences through Follow Me Homes. In this case, by observing various teams on Jira usage, we were able to identify the most critical user operations and to measure response times for:

1. Viewing the board
2. Viewing the backlog
3. Jira API search
4. Creating an issue
5. Adding a comment
6. Editing an issue
7. Auto-completing epics or labels
8. Transitioning an issue
9. Ranking an issue
10. Sprint operations
11. Viewing the dashboard
12. Viewing the project summary

We discovered that various operations were taking excessively long to complete. With some taking as long as 30+ seconds and others taking 6+ seconds or more, this was a source of user frustration. So, we focused on identifying the root cause of the slow performance and set ourselves a challenging goal: to reduce response times to under 3 seconds.

Identify root cause(s)

We explored a variety of factors that could contribute to performance bottlenecks. Initially we focused on reducing data size (archiving and deleting data), but this didn’t result in a significant improvement in performance since Jira’s well-structured schema and optimized database design allows for efficient data access, regardless of data volume. And, a check for database query inefficiencies and hardware resource utilization to support the Jira load didn’t turn up any issues.

However, we discovered several other opportunities for improvement:

• Poor utilization of webhooks — A webhook is a callback over HTTP that can send notifications to an external app or web application when certain events occur in Jira, such as updating an issue or starting a sprint. These webhooks are useful because they allow the remote application to receive notifications without constantly polling for events. However, they’re run in a blocking mode, which means that the Jira operation has to wait for the response from the remote application before continuing.
• Too many custom fields — Custom fields are a useful feature in Jira as they allow you to define additional fields beyond the default settings provided by the system. But it can have an impact on performance if they’re not used efficiently, or if there are too many of them. Custom fields can increase the size of the search results returned, and have too many inner joins to retrieve the results.
• Poorly optimized customizations and plugins — Customizations and plugins can also contribute to slow performance if they’re not optimized or are causing conflicts with other features.
• Java database connectivity (JDBC) tuning — The configuration of the connection between Jira and the database that can impact performance, for example:
• Connection pool size: This determines how many connections can be established between Jira and DB at given time. Too small value can lead to slow performance, as it delays the new connections. Too high value can result in too many context switching, and can have detrimental effect on the performance.
• Statement cache size: The statement cache stores prepared statements that can be reused to improve performance. If the statement cache is too small, it can lead to slower performance, as statements need to be prepared more frequently.
• Fetch size: The fetch size determines how many rows are retrieved from the database at a time. If the fetch size is too small, it can lead to more round trips to the database and slow down the performance.

Implement performance optimizations

Altogether, we concluded that we’d be able to dramatically improve Jira performance, and achieve our goal to reduce response times to under 3 seconds, by taking the following steps:

• Upgrade — To take advantage of product improvements and address performance issues, we upgraded our Jira instance from version 8.13 to 8.20, which also improved the auto completion of fields, such as epics or labels.
• Optimize webhooks — We have over 400 webhooks that are triggered by various events, such as create, update, or delete, and running as follows:
  The JQL (Jira Query Language) specified is executed to determine if the webhook should be triggered. If triggered, it waits for the response from the remote application, slowing down user operations.
  With our Jira upgrade, we benefited from a new “dark” feature to run webhooks in async mode, which we enabled using a special flag to significantly improve performance.
• Clean up custom fields — We had close to 500 custom fields, some of which served the same purpose but had different names, and many of which were defined with a global context. To improve performance, we deleted unnecessary custom fields and consolidated duplicate custom fields. Most importantly, we limited the scope of custom fields to the project context rather than the global context, which significantly improved the performance of Jira API searches. As a consequence, we’ve removed more than 100 fields.
• Finetune JDBC — Despite these changes, we found that sprint operations (such as creating, starting, or stopping/closing a sprint) continued to perform poorly, especially if the sprint contained a large number of issues. A detailed analysis revealed that changing the default JDBC value for pre-fetch rows to 200 significantly improved the performance of sprint operations. This required multiple trial and error analysis before we determined that 200 was the optimal value.

Celebrate!

As a result of these changes, more than 99% of user operations at the 90th percentile are completed within 3 seconds, leading to higher productivity and a significantly better user experiences for 3,000 projects and hundreds of workflows.

• “Jira performance has been much more reliable and is noticeably better during sprint planning the past few sprints. Thank you Jira team for your efforts.”
• “All the time teams have noticed a significant improvement in performance, especially on Monday mornings when everyone is performing sprint planning.”
• “Jira has been much better for me personally, and it was a well-oiled machine during our planning meeting.”

The following table shows the comparison of performance before and after these changes for various operations:

It takes a village — thank you!

The engineering team at Intuit deserves a round of applause for their hard work and dedication in improving the performance of our Jira setup. Their technical expertise, commitment to excellence, and unwavering focus on delivering results have made a significant impact on the overall user experience. Special thanks to my colleagues Abhijeet Mense, Nirbhaya, Adithya S., Manish Jain, Laurent Benchimol and Mark Basler.

And, we’re grateful to Atlassian for being an excellent partner throughout our journey. Their customer support team worked closely with our engineering team to identify the root cause of performance issues and provided step-by-step guidance to resolve them. The monitoring / analytics tools provided visibility into system performance, helping us to quickly identify issues.

If this blog has peaked your interest in what it’s like to work on a high performing engineering team here at Intuit, visit here to join our talent community!