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:
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.
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.
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.
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.
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.
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.
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot