Redmine

How many members do you have on the project where you experience this issue? (rounded number).

In #33329, I've proposed two options (4 and 5) to avoid this performance issue, which one works better for you?

Hi

when it took 10 seconds to pop up, there is 900 members.
when it took 25 seconds, there is 2500 members.
it's linear

I prefer the option 4

Hello Marius,

Thank you for the patch #33329 that is good improvement for sure.
But we do have the same perfomance problem with 1300+ users.

watchable_object.visible?(user)

I don't think we need all users names listed when the search query is blank. so I would like to request option 4.

As a test, I made this change and it reduced loading time from 4 sec to 0.2 sec.

-       scope = @project.principals.assignable_watchers
+       scope = @project.principals.assignable_watchers.limit(100)

Hello

We have the same problem that watchers pop up window appears after a long time.

Config :

Environment:
  Redmine version                4.2.8.stable
  Ruby version                   2.7.6-p219 (2022-04-12) [x86_64-linux]
  Rails version                  5.2.8.1
  Environment                    production
  Database adapter               PostgreSQL
  Mailer queue                   ActiveJob::QueueAdapters::AsyncAdapter
  Mailer delivery                smtp
SCM:
  Subversion                     1.14.1
  Mercurial                      5.6.1
  Bazaar                         3.1.0
  Git                            2.30.2
  Filesystem                     
Redmine plugins:
  redmine_openid_connect         0.9.4

We have 3 000 users and when we want add watchers for an issue, it takes a while to appear the watchers box (20 seconds).

Is there a solution ?
- like limiting watchers for a project ...

Thank you for your help.

We have hit the same performance problems.
We have a project with 1125 members, it takes ~4s to show the windows and another ~3 to see the watcher added.
On projects with few users the action is almost immediate.

Our configurationOur configuration

Environment:
  Redmine version                5.0.5.stable
  Ruby version                   2.7.6-p219 (2022-04-12) [x86_64-linux]
  Rails version                  6.1.7.2
  Environment                    production
  Database adapter               Mysql2
  Mailer queue                   ActiveJob::QueueAdapters::AsyncAdapter
  Mailer delivery                smtp
Redmine settings:
  Redmine theme                  Purplemine2-2.14.0
SCM:
  Subversion                     1.10.2
  Mercurial                      4.8.2
  Git                            2.31.1
  Filesystem                     
  Gitlab                         4.14.0
Redmine plugins:
  redmine_agile                  1.6.5
  redmine_gitlab_adapter         0.2.1
  view_customize                 3.3.0

5.1.3.stable - same issue. We have 242 users, and the Watchers pop-up takes about 5-10 seconds to open.

Member Load (32.1ms)  SELECT `members`.* FROM `members` INNER JOIN `projects` ON `projects`.`id` = `members`.`project_id` WHERE `members`.`user_id` = 274 AND `projects`.`status` != 9 AND `members`.`project_id` = 8 ORDER BY `members`.`id` ASC LIMIT 1
Role Load (32.1ms)  SELECT DISTINCT `roles`.* FROM `roles` INNER JOIN `member_roles` ON `roles`.`id` = `member_roles`.`role_id` WHERE `member_roles`.`member_id` = 5706

The patch mentioned in #note-10 looks good to me.

I tested it with a project containing over 4,000 members and confirmed that it improves performance. I also verified that pagination works correctly on Chrome, Safari, and Firefox.

All tests pass as well.

Unlike #44350, where I found the reported slowness was largely a Bullet-gem artifact (see #44350#note-18), this one is a real problem regardless of Bullet. With ~4000 members, opening the watcher dialog:

• trunk, Bullet on (default): ~6.5-7.2s
• trunk, Bullet off: ~6.0-6.5s — barely different, so Bullet isn't the cause here
• trunk, Bullet on + watcher-dialog-load-more-v2.patch: ~0.16-0.30s

I've confirmed that the patches attached in #note-14 and #note-15 work as expected in Chrome, Safari, and Firefox and resolve this performance issue. Looks good to me.