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.
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?
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.
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.
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.
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.
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event