#6677 User profile's list of projects is slow to build
closed
General
2015-08-20
2013-09-19
No
With 54 projects, a ridiculous amount of ming & mongo calls are executed on a profile page:
{
"url": "/u/brondsem/profile/",
"uptime": 1820,
"call_counts": {
"socket_write": 1,
"jinja": 1,
"mongo": 30396,
"total": 1,
"socket_read": 14,
"ming": 1102
},
"request_category": "profile",
"timings": {
"mongo": 2618,
"ming": 1328,
"socket_write": 0,
"socket_read": 93,
"total": 4528,
"jinja": 4478
}
}
Great
This should be limited to named ALLOW roles. As-is there are a variety of other projects showing up when they shouldn't be.
The problem isn't ALLOW vs DENY (the
has_access('read')check was added back to cover that) but the fact that most projects are open readable and we have a ton of auto-generatedProjectRoles associating users to projects that they simply viewed once, even if they're not assigned to any groups.We need to confirm that the user is actually assigned to some (named) group. In theory, the user's
ProjectRoleitself could be used directly in the ACL, but AFAIK that's only done when blocking a user (which isn't relevant to projects and would be handled by thehas_accesscheck anyway). I think just checking if the user roles cache item has any entries may be enough, but worst-case we just have to pull all theProjectRoles referenced in the user roles' roles lists (not quite as bad as the entire reaching roles set, and we could do it as a single query againstProjectRolelike is now done for theProjectquery) and check the name on each (to ensure it's neither anon nor auth).Have I mentioned that I dislike our permissions system?
allura:cj/6677