What is the recommended maximum issue count for Jira?

[crf]

Any answer that anybody gives you without knowing what kind of hardware we are talking about is clearly just making things up.  Things like number of CPUs, disk speeds, disk types, network connectivity, whether your database is local or provided by a service, and on and on and on – in general, hardware matters.

That said, I can offer the following data points that may be helpful for guessing:

• A sampling from March 2015 of those enterprise customers that were willing to provide this information to us yielded a 90%ile of about 250,000 and a maximum of more than 2 million.
• Over the years, the largest single instance I have encountered had over 8 million issues on it at the time.
• We use several different data sets for our in-house performance testing, and the two that we most commonly use have 200,000 and 450,000 issues.  This is not because we consider these to be performance limits of any kind; it's because that's enough to be convinced that we have adequate test coverage.

Performance problems in JIRA generally arise from the complexity of the configuration rather than the sheer volume of issues.  Custom fields with various configurations, a large number of issue security schemes, and nested groups across multiple user directories are all things that, though they are powerful and flexible, do not come for free.  Reducing the complexity of your configuration will generally be much more important than reducing the number of issues.

[dmitri]

we see the QuickCreateIssue endpoint take 1.3 seconds...is that poor performance? we have ~600k issues.

[dmitri]

and yes security rules. how do we measure that impact?

[crf]

Anecdotally, I would say that users tend to start getting slightly annoyed somewhere in the 0.5 - 1 second range, pretty irritated in the 1-3 second range, and completely furious in the 3-5 second range, after which they tend to start giving up or hitting refresh multiple times even though that is actually more likely to make things worse.

There are definitely pages in JIRA that are not well behaved (the bulk edit/move wizards and several of the admin pages come to mind).  QuickCreateIssue is not one of those.  I think performance problems have been noticed for it on systems with large numbers of projects, custom field configurations, etc., but I don't know the details offhand.

In any case, I think it's likely that my general answer probably applies to your situation.  The number of issues that exist should have no appreciable impact on QuickCreateIssue's performance; that is almost certainly going to be due to the sheer complexity / number of administrative configurations you have in place.

[crf]

There are many tools available to do performance testing on software.  JIRA internally uses a combination of tools for this, mostly based on webdriver tests using page objects built for testing the UI and/or special versions of them specific to the performance test suite.  The possibility of sharing these tools publicly has been discussed many times, but in their present form they are so strongly tuned to our internal testing environment specifics and so poorly documented that they aren't really suitable for public consumption.

The shortest and most honest answer I can give you is that if you want to measure the impact of changes, the best way to do that is to build a test environment where you can play around with them and measure this yourself, directly.

[Nelson Carranza]

Hi Chris,

Due to posting limits, this is on behalf of Dmitri:

"thanks. is there a standard way we should measure complexity of configuration?"

[crf]

Probably not, but here is a very rough stab based on the numbers I have available and assuming that you're in the 90%ile of the numbers I have, then it's something worth looking at.

• Issues: 1.2M
• Projects: 2100 (Likely transition point at 1000)
• Custom Fields: 2000 (Likely transition point at 1000)
• Workflows: 600
• Users: 100k
• Groups: 40k
• Permission Schemes: 450
• Total permission scheme entries: 1000
• Security Schemes: 150
• Field Configuration Schemes + Configuration Contexts: 200

These numbers should by no means be considered "authoritative" in any way; they are my personal suggestion as to where you might focus your efforts if you are having trouble.

The "transition point at 1000" that I mention is due to the way that some visibility queries are constructed.  There are cases where these build a large SQL IN clause.  On Oracle, these are limited to 1000 entries, so the shape of the query has to be modified at that point, usually operating in batches instead of as a single query.  We generally do try to avoid writing database-specific code if possible, so it would affect all databases, not just Oracle.  We've been working on identifying and eliminating these by rewriting them using subqueries instead of a preconstructed IN clause, but I would expect many of them still to remain at this time.

[GabrielleJ]

None  I've seen posts where they claim they have 1M issues in their JIRA instance. One of the biggest JIRA Instances I support/maintain have 600k issues and it performs pretty well. 

Are you concerned about JIRA performance on high issue counts? If yes, then issue count should not be on your list to check.