Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-35098

Poor performance of AutoBrowserHolder

    Details

    • Similar Issues:

      Description

      support-core analysis of slow requests turned up a case where rendering changelog information for a (Pipeline) job was consuming a lot of time with stack traces such as

      java.lang.String$CaseInsensitiveComparator.compare(String.java:1186)
      java.lang.String.compareToIgnoreCase(String.java:1239)
      hudson.util.CaseInsensitiveComparator.compare(CaseInsensitiveComparator.java:40)
      hudson.util.CaseInsensitiveComparator.compare(CaseInsensitiveComparator.java:34)
      jenkins.model.IdStrategy$CaseInsensitive.compare(IdStrategy.java:174)
      jenkins.model.IdStrategy.equals(IdStrategy.java:89)
      nectar.plugins.rbac.groups.Group.isMatch(Group.java:473)
      nectar.plugins.rbac.groups.Group.isMatch(Group.java:425)
      nectar.plugins.rbac.groups.Group.isMatch(Group.java:362)
      nectar.plugins.rbac.groups.GroupContainerACL.hasPermission(GroupContainerACL.java:157)
      nectar.plugins.rbac.groups.GroupContainerACL._hasPermission(GroupContainerACL.java:106)
      nectar.plugins.rbac.groups.GroupContainerACL.hasPermission(GroupContainerACL.java:72)
      hudson.security.ACL.hasPermission(ACL.java:73)
      hudson.model.AbstractItem.hasPermission(AbstractItem.java:505)
      com.cloudbees.hudson.plugins.folder.AbstractFolder.getItems(AbstractFolder.java:568)
      hudson.model.Items.getAllItems(Items.java:357)
      hudson.model.Items.getAllItems(Items.java:377)
      hudson.model.Items.getAllItems(Items.java:377)
      hudson.model.Items.getAllItems(Items.java:377)
      hudson.model.Items.getAllItems(Items.java:353)
      jenkins.model.Jenkins.getAllItems(Jenkins.java:1409)
      hudson.scm.AutoBrowserHolder.infer(AutoBrowserHolder.java:77)
      hudson.scm.AutoBrowserHolder.get(AutoBrowserHolder.java:64)
      hudson.scm.SCM.getEffectiveBrowser(SCM.java:136)
      org.jenkinsci.plugins.workflow.job.WorkflowRun.getChangeSets(WorkflowRun.java:612)
      com.cloudbees.workflow.rest.external.ChangeSetExt.hasChanges(ChangeSetExt.java:139)
      com.cloudbees.workflow.rest.external.RunExt.createOld(RunExt.java:324)
      com.cloudbees.workflow.rest.external.RunExt.create(RunExt.java:303)
      com.cloudbees.workflow.rest.external.JobExt.create(JobExt.java:126)
      com.cloudbees.workflow.rest.endpoints.JobAPI.doRuns(JobAPI.java:68)
      

      The top of the stack is specific to a proprietary AuthorizationStrategy, and the bottom is specific to pipeline-stage-view, but the middle clearly shows that SCM.getEffectiveBrowser is potentially rather expensive: if no RepositoryBrowser has been explicitly configured, and guessBrowser does not offer a default, then Jenkins will search all projects in the system (not including Pipeline) for similar SCM configurations which might let it infer the browser. The performance problem lies in the fact that a permission check must be done on each candidate project, lest a user of one job gain access to a secret SCM browser configuration from a job he would not otherwise be able to see (or even know of the existence of).

      This is an especially dubious feature in light of the fact that among all the OSS SCM plugins, there seem to be only two which actually implement isBrowserReusable: subversion; and cvs, which actually does so incorrectly (would produce bogus matches). So if for example you only use Git in your Jenkins installation, all this computation will be wasted.

      I propose to just delete this feature and deprecate the associated APIs. The more recently introduced guessBrowser is a more appropriate way to reduce the configuration burden for users of public hosting services. For users of private repositories, where guessBrowser is unlikely to work (depends on the SCM), various job templating systems are a more straightforward and predictable way of reducing repetition in Jenkins configuration.

      If there is someone who really finds this feature valuable, I think it would best be done as a plugin which explicitly offers to configure your repository browser on various jobs based on known examples; and/or there could be an extension point allowing for third-party contributions to guessBrowser. Either way, isBrowserReusable is not really needed for such features anyway; getKey (introduced alongside guessBrowser) is already more widely implemented and can be used for essentially the same purpose.

        Attachments

          Issue Links

            Activity

            jglick Jesse Glick created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Status Open [ 1 ] In Progress [ 3 ]
            jglick Jesse Glick made changes -
            Remote Link This issue links to "PR 2371 (Web Link)" [ 14342 ]
            scm_issue_link SCM/JIRA link daemon made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 171317 ] JNJira + In-Review [ 199068 ]
            jglick Jesse Glick made changes -
            Labels performance scm lts-candidate performance scm
            olivergondza Oliver Gond┼ża made changes -
            Labels lts-candidate performance scm 2.7.3-fixed performance scm
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal OSS-1005 (Web Link)" [ 18790 ]

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                jglick Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: