Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-5959

ServiceDesk sd.use.search.by.permissions feature flag might cause slow user picker search

XMLWordPrintable

      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

        1. image-2021-05-11-16-29-05-394.png
          image-2021-05-11-16-29-05-394.png
          153 kB

          Form Name

            [JSDSERVER-5959] ServiceDesk sd.use.search.by.permissions feature flag might cause slow user picker search

            Tripta Kaur made changes -
            Remote Link New: This issue links to "Page (Confluence)" [ 985249 ]

            Craig Castle-Mead added a comment - - edited

            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:

            • Dark Feature "sd.use.search.by.permissions.disabled" enabled - we need this as we have numerous JSM Projects with 100,000+ customers (global service desks) and without the flag set, it takes 25+ seconds to get search results when adding a Request Participant.

            With this setting:

            • The search that is triggered by Request Participants works as expected - the URL being /rest/servicedesk/1/servicedesk/sd-user-search/participants?projectId=12345&query=namegoeshere
            • However, when trying to change the Reporter, the API used is /rest/internal/2/users/reporter?maxResults=100&projectKeys=PROJ&query=namegoeshere  - and this only shows users who have the "Browse Project" permission, which for us is only JSM Agents. We cannot give this permission to customers, as it'd mean they'd be able to see all of the issues, even if they weren't the reporters. 

            So, we are left with the choice of:

            1. sd.use.search.by.permissions.disabled on
              1. Benefit
                1. Have usable performance on SD's when customers are trying to search for participants (as expected)
              2. Downside
                1. Any SD project will require entering the complete email address to change the reporter unless the user you're searching for is also a JSM Agent on that project
            2. sd.use.search.by.permissions.disabled off
              1. Benefit
                1. In SD projects, you can change reporter using the standard User search, and it'll show all customers (as expected)
              2. Downside
                1. Every SD project with a "large number of users" (10K+ is the value stated on this ticket) will have unusable user search for customers due to horrifically designed SQL queries

            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

            Craig Castle-Mead added a comment - - edited 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: Dark Feature "sd.use.search.by.permissions.disabled" enabled - we need this as we have numerous JSM Projects with 100,000+ customers (global service desks) and without the flag set, it takes 25+ seconds to get search results when adding a Request Participant. With this setting: The search that is triggered by Request Participants works as expected - the URL being /rest/servicedesk/1/servicedesk/sd-user-search/participants?projectId=12345&query=namegoeshere However, when trying to change the Reporter, the API used is /rest/internal/2/users/reporter?maxResults=100&projectKeys=PROJ&query=namegoeshere  - and this only shows users who have the "Browse Project" permission, which for us is only JSM Agents. We cannot give this permission to customers, as it'd mean they'd be able to see all of the issues, even if they weren't the reporters.  So, we are left with the choice of: sd.use.search.by.permissions.disabled on Benefit Have usable performance on SD's when customers are trying to search for participants (as expected) Downside Any SD project will require entering the complete email address to change the reporter unless the user you're searching for is also a JSM Agent on that project sd.use.search.by.permissions.disabled off Benefit In SD projects, you can change reporter using the standard User search, and it'll show all customers (as expected) Downside Every SD project with a "large number of users" (10K+ is the value stated on this ticket) will have unusable user search for customers due to horrifically designed SQL queries 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
            SET Analytics Bot made changes -
            UIS Original: 5 New: 4
            Marc Dacanay made changes -
            Labels Original: deltaUserCache performance pse-request New: deltaUserCache performance pse-request ril
            Marc Dacanay made changes -
            Remote Link New: This issue links to "Internal ticket (Web Link)" [ 955093 ]
            SET Analytics Bot made changes -
            Support reference count Original: 9 New: 10
            SET Analytics Bot made changes -
            UIS Original: 6 New: 5
            SET Analytics Bot made changes -
            Support reference count Original: 8 New: 9
            SET Analytics Bot made changes -
            UIS Original: 7 New: 6
            SET Analytics Bot made changes -
            UIS Original: 6 New: 7

              Unassigned Unassigned
              ayakovlev@atlassian.com Andriy Yakovlev [Atlassian]
              Affected customers:
              14 This affects my team
              Watchers:
              16 Start watching this issue

                Created:
                Updated: