JIRA - How many tickets you have in your JIRA?

[Mirek]

I am just wondering .. Are there any limits in number of tickets in JIRA? What is the biggest number of issue that you have in your instances? Is this normal to have more that 1 milion issues on a single instance? If someone is having so big number .. what about performance?

[Jonas Andersson · Accepted solution]

That's a very good question that i spent a lot of time looking into. Very many factors determine how fast your JIRA will run. I have administered a 1m issue JIRA instance, but i am not sure how many instances like this exist. I assume that almost every 10.000 user instance of JIRA at some point will reach this size. It can be solved doing performance tuning, avoiding common mistakes that makes JIRA slow.

A great article written on the topic of performance tuning large instances is written, and this guy put in a lot of time tweaking and measuring it, so it's well worth a read:

http://www.scoop.it/t/atlassian-stuff/p/4015453322/2014/02/06/how-to-make-jira-6-1-2-times-faster-onresolve-team-blog

Another option is running 2 JIRA instances in what is called a federated fashion. This allows you to migrate projects to a server that is only used for archived issues, where permissions schemes are set to not allow updates, which in terms removes the need for verifying some permissions, caches to read through them (at least on the instance used by users).

Some information about running JIRA federated can be found here:

https://confluence.atlassian.com/display/ENTERPRISE/Federating+JIRA+-+Managing+Multiple+Instances

[MattS]

If you could search across federated instances from within JIRA, that would make scaling easier

[MattS]

Also, Jamie's 6 1/2 article is from 2009

[MattS · Accepted solution]

A million issues puts you in the big JIRA category. The best way to scale is to get rid of some of those issues, but many legal teams have data retention policies that won't let you delete anything, ever. So you want to archive those issues but you there's no great long-term solution for that apart from splitting your JIRA periodically into federated instances, with no federated searching.

Another dimension to watch carefully is the number of custom fields. 600 is a common recommended maximum number, but you can add more. The problem is this makes the Lucene index (used for JQL searches) very large (>10GB), which can then become a bottleneck when many concurrent users update issues.

Despite these warnings, if you keep your Lucene index on a fast local disk, then JIRA search speed scales really rather well.

https://confluence.atlassian.com/display/JIRAKB/Crashes+and+Performance+Issues+Troubleshooting has a long list of other things that you should consider at the megaissue scale.

[Mirek]

Matt, thank you for the comment. I agree completely. I am just wondering.. what was the biggest instance looking at the number of issues that you saw? Is it more than a million that Jonas administer?