Defect #5942
openGroups with a few thousand users gives issues in a few UIs and slow-downs on a few screens
0%
Description
We have a reasonably-sized community redmine installation for our open-source projects on a dedicated 4-cpus virtual server, running latest 1.0.0-RC release (admin information says 1.0.0.Stable btw :-) ). 130,000 users registered there, around 100 projects.
All running pretty well until we added just a few thousand users to a group, which is member of a dozen projects.
But now there are a few user interfaces which are not adapted anymore and sometimes crashing the server-side or browser:
- Project Overview: displays in detail all users of the group instead of just the group as member, that takes a few seconds to compute and a few more to display.
I've written a small plugin to override the view and not display all members in the view, but the model/controller still fetches all users, which takes lots of time to do that.
- "New Issue" by manager or admin: "Add watcher" are checkboxes taking long time like 15 seconds to compute, load and display. There another UI element, with ajax user search when there are more than let's say 50 members that are able to watch, should be used instead IMHO.
- Settings: all members are displayed there in the "Members" tab with an "Edit" link that just allows to change level, leading to an html page of over 10 MegaBytes taking 30 seconds to compute, and as long to render. IMHO members of project because of membership in a group that is member of the project should not be displayed there. This is the biggest issue right now, as it is very very slow and huge html.
I've also looked at the underlying database structure, and saw that users are added to each project where their group is member, in project's members and member_roles tables in addition of the group being also added to those tables. While being redundant in terms of database design, I imagine that this makes authorization more efficient ? But at least in the administration UI, IMHO inherited_roles should not be displayed at all in lists, only non-inherited roles' members.
Also, looking at MySQL queries to see if something is runing non-indexed, I saw this query which can't use indexes because of the complex WHERE statement running slowly, specially in sorting:
SELECT * FROM `users` WHERE (users.type='Group' OR (users.type='User' AND users.status = 1)) ORDER BY type, login, lastname ASC LIMIT 100