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

Creation of trend graphs is slow on large number of builds

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: robot-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      With over e.g. 200+ builds the generation of trend graphs for duration and test result takes several seconds.

        Attachments

          Activity

          Hide
          grayaii Alex Gray added a comment -
          Show
          grayaii Alex Gray added a comment - Could be related to:  https://issues.jenkins-ci.org/browse/JENKINS-15818
          Hide
          dirkrichter Dirk Richter added a comment - - edited

          Analysis of output.xml on 200+ builds means a lot of cpu, which seems to be normal for me!

          I see 3 possible solutions:
          1. Did you consider to use parameter "Max builds" (e.g. set to 20)? Then the last 20 builds are shown only.
          2. Did you consider to automatically discard old builds? You can configure amount of days of amount of builds to keep in project configuration.
          3. Currently the image generation is on demand and starts, when user requested it via frontend. Robot-Plugin could precompute such images when the build is finish.

          Show
          dirkrichter Dirk Richter added a comment - - edited Analysis of output.xml on 200+ builds means a lot of cpu, which seems to be normal for me! I see 3 possible solutions: 1. Did you consider to use parameter "Max builds" (e.g. set to 20)? Then the last 20 builds are shown only. 2. Did you consider to automatically discard old builds? You can configure amount of days of amount of builds to keep in project configuration. 3. Currently the image generation is on demand and starts, when user requested it via frontend. Robot-Plugin could precompute such images when the build is finish.
          Hide
          aaronm Aaron Miller added a comment -

          Hello,

          Would you consider adding an option to disable the trend graph either in the global plug-in config and/or per job?

          The suggested solutions are not ideal for us:

          1. This requires each user to change that parameter, individually on each job. Also it looks like the setting is stored in their browser cache, correct? So if that is cleared they will need to do it again. And users who don't bother are potentially using up a lot of CPU cycles on our master any time they view a project.
          2. While this would work, it feels a bit like the tail wagging the dog. We retain those builds for business reasons, removing them to improve performance of a feature we don't need is not a direction we'd like to go.
          3. While better than the current situation, this is still potentially using a lot of CPU cycles on our master for a feature that we aren't interested in.

          Thank you!

           

          Show
          aaronm Aaron Miller added a comment - Hello, Would you consider adding an option to disable the trend graph either in the global plug-in config and/or per job? The suggested solutions are not ideal for us: This requires each user to change that parameter, individually on each job. Also it looks like the setting is stored in their browser cache, correct? So if that is cleared they will need to do it again. And users who don't bother are potentially using up a lot of CPU cycles on our master any time they view a project. While this would work, it feels a bit like the tail wagging the dog. We retain those builds for business reasons, removing them to improve performance of a feature we don't need is not a direction we'd like to go. While better than the current situation, this is still potentially using a lot of CPU cycles on our master for a feature that we aren't interested in. Thank you!  
          Hide
          aleksisimell Aleksi Simell added a comment -

          Hi Aaron Miller

          We could definitely look on a solution to have a "max builds to show" in global configs, potentially overwritable per job. This feature is already in place for X-axis label, so doing that for the amounts of builds to show should be doable.

          Show
          aleksisimell Aleksi Simell added a comment - Hi Aaron Miller We could definitely look on a solution to have a "max builds to show" in global configs, potentially overwritable per job. This feature is already in place for X-axis label, so doing that for the amounts of builds to show should be doable.
          Hide
          aaronm Aaron Miller added a comment -

          Hi Aleksi,

          It would be nice if the graph could be disabled totally. If "max builds to show" is set to a low value to avoid using much CPU, the graph isn't all that useful (but is still using some CPU). Not a huge deal though.

          Thanks!

          Show
          aaronm Aaron Miller added a comment - Hi Aleksi, It would be nice if the graph could be disabled totally. If "max builds to show" is set to a low value to avoid using much CPU, the graph isn't all that useful (but is still using some CPU). Not a huge deal though. Thanks!

            People

            Assignee:
            aleksisimell Aleksi Simell
            Reporter:
            jpiironen jpiironen
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated: