As an addendum to the previous post, I've done some more cleaning up, and JIRA is now 12 times faster on the average measurement.
|Create Choose type||9||289||141||677|
In addition to tweaking permission schemes, I also removed all redundant schemes (workflow, permission, notification, issue security), empty projects, workflows, and groups.
From a performance perspective the significant one of these is the groups. We have a process that creates a group for every project, and synchronises its membership with that of all the project roles, excluding jira-users. This was to work around a deficiency in an earlier version of jira where you couldn't share filters with a project's roles, only groups. Now you can though. So 500 of our 700 groups were not in use and were able to be deleted, this gave a further 20%-ish improvement.
IMHO this is due to problems with com.atlassian.jira.security.roles.actor.GroupRoleActorFactory.GroupRoleActor#getGroup, which gets a group using GroupUtils, then iterates over every group until it finds it again, to work around a bug where an invalid group can be returned if a user name is passed in. The code references JRA-15200 which doesn't seem right, however there are a number of related issues. Anyhow, currently it is apparently 0(N2), so reducing the number of groups is going to help. Update – grr, I've just seen this is fixed in 3.12.2 – JRA-16032. I can't upgrade right now and I don't want to cherry pick just that fix so I'm carrying on with removing groups.
Removing unused schemes doesn't help performance much I imagine, however admin becomes easier. The workflow schemes page is down to 14 screens from 22. Number of workflows down from 268 to 133. The feature for creating draft workflows is great, however when you save the previous version before replacement, you end up with lots of copies of previous versions. It would be better if it could append a .N which increases each time.
Rather than write a plugin I've just extended the integrity checker. Each one can be previewed before it will do anything.
The checks are:
Check jira-users is not in any permission schemes, and change the perm scheme if necessary
If a perm scheme uses the role Users, and in each project using that perm scheme the Users role contains jira-users, then this changes the permission in the scheme to Anyone, and removes the role from the perm scheme.
jira-users is hard-wired, if you use a different group for the USE permission modify accordingly.
This will also remove any redundant entries from perm schemes. If you have Anyone, and also a group with permission to CREATE, the group is redundant as it's already a subset of Anyone, yet can affect performance if checked first. So this deletes any superfluous entries.
Check projects can be moved to global perm scheme (requires scheme called: Default Permission Scheme With Global Browse)
Requires the existence of a scheme that has Anyone in place of Role: Users. For each project, where the two schemes are equivalent (based on the project role memberships) the permission scheme will be changed.
Remove unused projects over two months old
We had 70-odd unused projects, ie with no issues, so this deletes any that were created more than approximately two months ago. The approximation is because there is no project created field, so this looks at the first update date of every issue created in every project after this one to work out the latest this project could possibly have been created. Relies on the fact that project IDs are sequential and increasing.
Scheme and Workflow Checks
Removes schemes not associated with any project. Remove workflows not in any scheme (inactive) and edited over two months ago. Due to the nature of these you might need to run all the checks several times so that they all pass. Eg, deleting an unused project may make a workflow scheme inactive. Deleting that scheme may make several workflows inactive that can be deleted. Deleting these workflows may make some groups inactive (if used as conditions for instance).
Check all groups are in use, remove them otherwise
Remove groups that are not in use in any of:
- As parameters in filters
- Project roles
- Schemes of any types
- Dashboard or filter shares
There isn't a test that groups are used in global permissions, in my case they were all in use elsewhere.
I'm sticking this out there in the hope that it will be a useful starting point for large installations with performance problems, rather than a silver bullet. As it involves a small patch to a jira class this is source only.
- Unpack the distribution and build: mvn -Dgmaven.runtime=1.5 compile.
- Overlay the WEB-INF/classes directory with the build output, from target/classes.
- Add the embeddable/groovy-1.5.X.jar from http://groovy.codehaus.org/Download. I've tested 1.5.7, other 1.5.X versions may work.
- Restart jira and you should see the additional integrity checks.
It goes without saying that you should a) review the fixes carefully before pressing the Fix button, and b) run on a copy of your test database first.