Historically, a `ProjectRole` with an empty `roles` list was automatically
created for a user when they viewed any given project. We've since optimized
that to only upsert when explicitly needed, but just because there exists a
`ProjectRole` for a given `User` / `Project` combination doesn't mean that user
actually has any access to the project.
We could check to see if `c.user == self` to skip the `has_access` checks, but
in most cases we're still going to need to call `has_access`. :-/
The optimization to pull in all `Project`s at once instead of using
`role.project` is good, and should be extended to `my_projects_by_role_name`.
Also, since that is now a separate method to avoid the extra queries needed by
the reaching logic, please also make the parameter non-optional.
---
** [tickets:#6677] User profile's list of projects is slow to build**
**Status:** code-review
**Labels:** performance 42cc
**Created:** Thu Sep 19, 2013 08:20 PM UTC by Dave Brondsema
**Last Updated:** Thu Jan 30, 2014 08:56 AM UTC
**Owner:** nobody
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
}
}
~~~~
---
Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed
to https://sourceforge.net/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
