What harms more to JIRA performance? number of issues or number of projects?

[Hansoo Bae]

We think, we  have very large number of issues and projects.

We're currently in progress of reducing the number of projects with some more custom fields. but we cannot reduce the number of issues. 

currently we have more than 10,000 projects and more than 140,000 issues in JIRA software data center 7.10.1 ( 2 user nodes 12G Mem each and separate API only node for external interface). 

Recently we have some issues with performance, sometimes we even got time out.  At the peak time, there are not more than 200 concurrent users. 

We're trying to reduce the number of projects, because it could impact the performance, but I still think that the number of issues, which we cannot reduce, could be more influential to the performance. 

Any suggestion or discussion or answers would be really appreciated. 

[Steven F Behnke · Accepted solution]

We have several hundred projects (500 or less) and 900,000 issues about. Performance is okay, the worst part is that we have 2,400 Custom Fields all set to GLOBAL, which I am reducing. I have about 1,000 concurrent users.

In my opinion, Issues don't really seem to matter for performance. However, how the hell do you have 10k projects?

[Hansoo Bae]

We thought that the users would manage their projects wisely... (we're not SW company, we're using JIRA for managing sort of  marketing campaigns and also for 3rd party communication and invoice tracking and etc)  

We're reducing the projects to not more than 10 projects now. so number of projects can be reduced :-) 

Thanks for your opinion.

[Steven F Behnke]

Ahh, I understand that. I've had to propose that same change. One department at the company I work at was making one project for each event. I encouraged them to use a Field instead (for the 'Event' instead of a new Project). It allows for a much smaller set of associations and should make querying things much easier. Good luck sir.

[Nic Brough -Adaptavist-]

One thing that is indirectly related to volume of projects is permissions.  Every time someone *might* want to do something, Jira does a permission check.  These can be quite complex if you've got complex permissions. 

Simplify them where you can - share standardised schemes, and most importantly, use roles.

If you can, there's one extra trick - use the group "anyone" in "Browse project".  This grants "anonymous" access, so you do need to be very careful, but if you can use it, it makes the logic behind the largest checks (can I even see this issue?) a lot more simple.  Instead of "who is this, can they see the issue according to the permissions", the logic becomes "if anonymous access allowed, they can see it" - it bypasses all checks on roles, group membership and even reading the user.

[Hansoo Bae]

We're using not more than 20 shared schemes (screen, field, permission and so on) from the beginning because of the reason that you mentioned and trying to reduce more. 

Unfortunately we cannot use "anyone" group in "Browse project" because of the compliance, legal and internal reasons. 

But I see you point and Thank you very much for your answer. 

[Hansoo Bae]

I can see that the number of issues maybe not the problem from the situation @Steven F Behnke (more than 900,000 issues), I will see what happens after reducing the number of projects to below 200. 

Thank you @Steven F Behnke and @Nic Brough -Adaptavist- for great help.

[Nic Brough -Adaptavist-]

No problem, I mentioned the permissions as the general "use roles" can be of some help in some cases, and "keep it simple" applies to every area, not just permissions. 

If you can't use "anonymous access" because of the nature of your system, then you can't - it's not something I would push if there's any decent business or security reason for not having it.

[Stephanie Ong]

Is that mean have a new role is much better than creating more permission scheme? 
Creating new role will it cause performance issues ?