[#JRA-12610] Poor performance with large numbers of Users in roles.

JIRA

Poor performance with large numbers of Users in roles.

Created: 22/Apr/07 06:57 PM Updated: 07/May/07 07:28 PM

Component/s:

Performance, Roles

Affects Version/s:

None

Fix Version/s:

3.9

Time Tracking:

Not Specified

File Attachments:

None

Image Attachments:

1. permscheme.png
(67 kB)

2. projectroles.png
(25 kB)

Participants:	Jed Wesley-Smith [Atlassian] and Jeff Turner [Atlassian]
Since last comment:	2 years, 9 weeks, 1 day ago
Resolution Date:	02/May/07 07:10 PM
Labels:

Description

« Hide

If I:

define a permission scheme granting the "JIRA Users" role the Browse permission:
in each project, map the 'jira-users' group to the project's JIRA Users role (this will be done automatically if 'jira-users' is configured as a role default member):

Then many parts of JIRA (notably dashboards) can run slowly if you have many users. With 45,000 users, a standard dashboard will take ~10s to render. If the 'jira-users' group is mapped directly to the Browse permission (logically equivalent), the same dashboard takes 300ms to render.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Jed Wesley-Smith [Atlassian] added a comment - 26/Apr/07 11:23 PM

There are two parts to this.

The RoleActor caching is extremely inefficient
The way the user permission check is performed is inefficient.

We are addressing both of these at once.

[ Permalink | « Hide ]

Jed Wesley-Smith [Atlassian] added a comment - 02/May/07 07:10 PM

Cached RoleActors are now immutable and returned by reference to Permission checks. UserRoleActors are now aggregated into a map and looked up by user name to optimise looking up users in when large numbers in a project role. This is now a sub 10ms action in a 900 project database with large numbers of users in roles across projects. Tested for both positive and negative permission cases, as well as under highly concurrent usage (>50 concurrent requests).