Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-59701

Inefficient user count in UserSearcherHelperImpl.getSuggestedUsers()

    XMLWordPrintable

Details

    Description

      On JAC there has been cases where some requests that perform JQL queries (e.g. https://jira.atlassian.com/issues/?jql=) take a long time (30+ seconds).

      This seems to be due to UserSearcherHelperImpl.getSuggestedUsers() performing a count of billable users unnecessarily. It should be possible to replace this billable users count code with a limited UserSearchService query which would make it more efficient.


      From the comment of the HOT ticket:

      It seems for some users the number of billable users is being retrieved which is expensive. The stack dump shows this call running:

              ...
              at com.atlassian.jira.application.DefaultApplicationRoleManager.totalBillableUsers(DefaultApplicationRoleManager.java:554)
      	at com.atlassian.jira.issue.search.searchers.util.UserSearcherHelperImpl.getSuggestedUsers(UserSearcherHelperImpl.java:134)
      	at com.atlassian.jira.issue.search.searchers.util.UserSearcherHelperImpl.addUserGroupSuggestionParams(UserSearcherHelperImpl.java:77)
      	at com.atlassian.jira.issue.search.searchers.util.UserSearcherHelperImpl.addUserGroupSuggestionParams(UserSearcherHelperImpl.java:69)
      	at com.atlassian.jira.issue.search.searchers.renderer.AbstractUserSearchRenderer.addUserGroupSuggestionParams(AbstractUserSearchRenderer.java:225)
      	at com.atlassian.jira.issue.search.searchers.renderer.AbstractUserSearchRenderer.getKickassVelocityParams(AbstractUserSearchRenderer.java:190)
      	at com.atlassian.jira.issue.search.searchers.renderer.AbstractUserSearchRenderer.getVelocityParams(AbstractUserSearchRenderer.java:169)
      	at com.atlassian.jira.issue.search.searchers.renderer.AbstractUserSearchRenderer.getEditHtml(AbstractUserSearchRenderer.java:88)
      	at com.atlassian.jira.components.query.DefaultSearcherService.getEditHtml(DefaultSearcherService.java:412)
      	at com.atlassian.jira.components.query.DefaultSearcherService.getValueResults(DefaultSearcherService.java:230)
      	at com.atlassian.jira.components.query.DefaultSearcherService.getSearchResults(DefaultSearcherService.java:165)
      	at com.atlassian.jira.components.query.DefaultSearcherService.searchWithJql(DefaultSearcherService.java:160)
              ...
      

      Normally the total billable users value is cached, but on JAC there seems to be a high turnaround of users - whenever a user is added or removed this cached count is blown away and the next request has to refresh the count. This count probably would take 20-30 seconds on a reasonably loaded system like JAC with 400k+ users.

      The code that calls it is from UserSearcherHelperImpl.getSuggestedUsers():

      ...
                  // JRADEV-15375 With a significant number of users in the system, a full sort is very slow and pointless to
                  // suggest random users anyway. On the other hand, we do like putting_something_in here for evaluators...
                  if (suggestedUsers.size() < limit && licenseCountService.totalBillableUsers() <= 10) {
                      // Suggest the first 'limit' users in the system (if they don't already appear).
                      List<ApplicationUser> allUsers = userSearchService.findUsers("", searchParams);
      ...
      

      Really this code only needs to know if there is more than 10 users in the system or not, there are less expensive ways to work this out - using UserSearchService.findUsers() with a limit of 10 (UserSearchParams.maxResults) would be much more efficient as the limit is passed through to the database and can be performed nearly instantly.

      Something similar to this fix in project templates plugin but with a limit of 10 instead of 2.

      Attachments

        Issue Links

          Activity

            People

              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              prunge Peter Runge (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: