Defect #5942
open
Groups 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
Updated by Beat over 14 years ago
For the third bullet above:
The following quick view-override for the project settings members tab view did at least get rid of the huge html avoiding to display users which are part of a group, and therefore not deletable:
diff app/views/projects/settings/_members.rhtml vendor/plugins/ourplugintooverrideviews/app/views/projects/settings/. 16c16 < <% next if member.new_record? %> --- > <% next if (member.new_record? || ! member.deletable?) %>
It still takes over 15 seconds to compute the page, as all members of the group are still loaded in memory, but now it displays only the groups and members of the project which have roles which are not inherited from a group.
Updated by Kioma Aldecoa over 13 years ago
I agree it would be very nice to have better control of who members are displayed.
Beat is there any way you could share your small plugin that makes it only display member groups on the overview page?
Updated by Terence Mill over 13 years ago
Beat wrote:
For the third bullet above:
The following quick view-override for the project settings members tab view did at least get rid of the huge html avoiding to display users which are part of a group, and therefore not deletable:
What make you think they are not deletable? If a project manager can manage users he can still delete the whole group from his project