Does the number of issues significantly slow down JIRA?

Shane Corley April 4, 2016

We want to create an inventory of our company's servers on JIRA. We have 1000 servers we want to upload as issues. We also use JIRA for normal project management. Let's just say that our JIRA server eventually had 100,000 issues, does this have a significant effect on JIRA's performance?? Thanks!

 

2 answers

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 4, 2016

Yes, as JIRA grows, you'll find some things get a bit slower.  There's no simple "number of issues = certain load" rule though because the factors are number of issues, projects, patterns of use, active users, types of use, integrations and more (although it's number of users and complexity of permissions at the top of the list)

Modern hardware will work fine for 100,000 issues though.  I'd use the word "large", but it's at the lower end of that classification (I've worked with 2 million issues in older versions of JIRA where the code really didn't scale at all, unlike now, where it's much improved, and that was workable)

You will be fine, but you'll want to monitor it as it grows.  Lovely general principles are covered by Dan over at https://summit.atlassian.com/archives/2013/inside-the-massive-team/the-not-so-dark-art-if-atlassian-performance-tuning   (Yes, I work for Dan, so I'm a bit biased, but even if I hadn't been there for all his practice runs and worked for someone totally different, it's still an excellent talk)

0 votes
Steven F Behnke
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 4, 2016

No, not really. It honestly depends on your usage. 

JIRA only returns 50 at a time in the Navigator, and only 1000 at a time via API – This offers consistent performance as you page through the results depending on your method of choice. Where I have seen issues is when teams attempt to hook a backlog of 3,000 issues up to a Scrum Board – The performance of a small-team board using a backlog of that size is poor.

Usually I see poor performance when the system-host or the JVM settings aren't tuned for the instance. This typically results from system administration who doesn't know how to handle java-based applications running in Tomcat.

Plugins and other customizations will affect performance much more than issues. Ultimately resolving all issues that are done, canceled, etc is the best way to go. That removes them from a lot of reporting calculations.

Suggest an answer

Log in or Sign up to answer