nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Steven F Behnke

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?

All comments

Steven F Behnke

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server