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

Default health metric is potentially expensive

      Rendering the weather column when WorstChildHealthMetric is used causes the last six builds of any contained jobs (even in subfolders) to be loaded into memory if they were not already. This can cause slow rendering times for the home page in a large installation.

      Perhaps WorstChildHealthMetric.DescriptorImpl should not override createDefault. That would at least ensure that by default folders would not do expensive computations on child jobs. This would be helpful in installations contains lots of jobs grouped into folders (and no top-level jobs).

      Of course administrators can manually remove all health metrics from folders, but they have to know to do this, when it is by no means obvious that this is the cause of slow view rendering. I think you should need to opt in to something which may add performance overhead.

      Would do no good on folders whose configuration has already been saved at least once, and healthMetrics persisted. But would be useful on newly created folders.

      Also help.html of any metric which loads builds should mention this fact.

          [JENKINS-25078] Default health metric is potentially expensive

          Jesse Glick added a comment -

          Implementing JENKINS-25075 would make the current default behavior not block page render times, but it would still add overhead to the server, just more incrementally.

          Jesse Glick added a comment - Implementing JENKINS-25075 would make the current default behavior not block page render times, but it would still add overhead to the server, just more incrementally.

          Nicolas De Loof added a comment - - edited

          I wonder we could use a simple workaround to have a Job / Folders property for health status, only updated on build completion, vs re-computing any time page is accessed.

          Nicolas De Loof added a comment - - edited I wonder we could use a simple workaround to have a Job / Folders property for health status, only updated on build completion, vs re-computing any time page is accessed.

          Jesse Glick added a comment -

          Job.cachedBuildHealthReportsBuildNumber/cachedBuildHealthReports is already supposed to do this, but it is not enough to prevent expensive calculations on some renders.

          Jesse Glick added a comment - Job.cachedBuildHealthReportsBuildNumber/cachedBuildHealthReports is already supposed to do this, but it is not enough to prevent expensive calculations on some renders.

          Jesse Glick added a comment -

          For better discoverability, Folder.getBuildHealthReports could check for an empty reporter list, and if so display a special report (with no icon) that just offers the hint that you can enable metrics if you want them.

          Jesse Glick added a comment - For better discoverability, Folder.getBuildHealthReports could check for an empty reporter list, and if so display a special report (with no icon) that just offers the hint that you can enable metrics if you want them.

          Ryan Campbell added a comment -

          Stephen says this bug should be fixed by https://github.com/jenkinsci/cloudbees-folder-plugin/pull/73

          Ryan Campbell added a comment - Stephen says this bug should be fixed by https://github.com/jenkinsci/cloudbees-folder-plugin/pull/73

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: