-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
3.3.2, 3.6.2, 3.9.6, 4.5.5
-
10
-
Severity 2 - Major
-
4
-
Summary
Closed Access Service Desks with sd.use.search.by.permissions feature flag set (default), might have slow user picker search.
see KB for more details: Closed Access Service Desks, slow user picker search
Environment
- a large number of users 10k+
- The dark feature sd.use.search.by.permissions.disabled is not activated.
- Closed Access ServiceDesks
- Who can raise requests? set to Customers who are added to the project.
Expected Results
User picker search is fast and doesn't have extra memory/SQL pressure
Actual Results
User picker search can be slow and have extra memory (see JSDSERVER-5958)/SQL pressure
Notes
- In case of Closed Servicedesk, code takes users by permission and does additional filtering. Unfortunately, increased memory consumption (and interoperability with lazy user cache) wasn't taken into account.
- Overall disabling of this feature flag doesn't affect search results but has an effect on performance. With it disabled open and closed servicedesk will go through the same execution path.
Workaround
- Disable "sd.use.search.by.permissions" feature flag, see KB Closed Access Service Desks, slow user picker search
- is related to
-
JSDSERVER-5958 High memory usage for Closed Service Desk projects with Group Anyone permission
-
- Gathering Impact
-
- relates to
-
JSDSERVER-6889 Typing query into JSD "Alert user" automation "THEN" action causes constant GC and service instability
-
- Gathering Impact
-
- links to
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
While sd.use.search.by.permissions.disabled being enabled definitely addresses the significant performance issue for user searching, it changes the behavior of the Reporter search in an unexpected fashion, it only seems to have been tested with the Request Participant user search.
System setup:
With this setting:
So, we are left with the choice of:
Given JSM is constantly advertised to Enterprises, 10,000 users is so far from an expected number of users that the product should support in a much better fashion than this.
For a pretty standard use case, we shouldn't have to be picking between bad performance and bad UX,
CCM