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

Split main configuration page, takes too long to load

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      Over time, we encountered that the main Jenkins configuration page took longer and longer to load. We suspect that this stems from an ever increasing number of templates defined in clouds, which also multiplies by the number of configured clouds.

      It would therefor be nice if some parts were separated from the main configuration, namely said clouds incl. agent templates and maybe the global environment variables (we also have quite a few of them).

        Attachments

          Activity

          Hide
          pjdarton pjdarton added a comment -

          I think that this issue isn't really about the docker-plugin, but it's more about the core - when there are a lot of "cloud" instances configured, the main config page takes ages to load.
          We've got the same symptoms, but that's mostly from vSphere and OpenStack clouds - there's a lot of field verification going on all at once, and this takes time.

          FYI one of the changes I made to the docker plugin was to hide a lot of information within "optional" sections so that the web-page wasn't horribly long by default, allowing the Jenkins admin to only "expand" the sections they were interested in, but this doesn't make much difference to loading speed, only to the visual appearance and navigability of the page.

          I think the solution here is for the core to automatically split out the "Clouds" bit into multiple pages when it starts to get large. That isn't an enhancement that belongs to the docker-plugin, that's a wider issue.

          What I would suggest is that the Jenkins main jelly code has some sort of "if clouds.size>=1 then punt Clouds into its own page" logic, e.g. have a separate "Clouds" section that magically appears when clouds.size>=1 and have the "Clouds" section in the main config magically turn from the current menu/list (that can become huge and slow) into a link to that new page whenever clouds.size >= 1.
          ...or, alternatively, make it unconditional, much like what was done when the Jenkins "thread dump" functionality was moved to its own page.

          Either way, it's not something that the docker-plugin can do on its own - that's a core issue. I'll amend the "components" field accordingly...

          Show
          pjdarton pjdarton added a comment - I think that this issue isn't really about the docker-plugin, but it's more about the core - when there are a lot of "cloud" instances configured, the main config page takes ages to load. We've got the same symptoms, but that's mostly from vSphere and OpenStack clouds - there's a lot of field verification going on all at once, and this takes time. FYI one of the changes I made to the docker plugin was to hide a lot of information within "optional" sections so that the web-page wasn't horribly long by default, allowing the Jenkins admin to only "expand" the sections they were interested in, but this doesn't make much difference to loading speed, only to the visual appearance and navigability of the page. I think the solution here is for the core to automatically split out the "Clouds" bit into multiple pages when it starts to get large. That isn't an enhancement that belongs to the docker-plugin, that's a wider issue. What I would suggest is that the Jenkins main jelly code has some sort of "if clouds.size>=1 then punt Clouds into its own page" logic, e.g. have a separate "Clouds" section that magically appears when clouds.size>=1 and have the "Clouds" section in the main config magically turn from the current menu/list (that can become huge and slow) into a link to that new page whenever clouds.size >= 1. ...or, alternatively, make it unconditional, much like what was done when the Jenkins "thread dump" functionality was moved to its own page. Either way, it's not something that the docker-plugin can do on its own - that's a core issue. I'll amend the "components" field accordingly...

            People

            • Assignee:
              Unassigned
              Reporter:
              dhs Dirk Heinrichs
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: