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

Investigate slow loading experience

    XMLWordPrintable

    Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      pacific, atlantic, 1.0-b05/b-06, arctic, tasman, frank

      Description

      When loading dogfood, or even locally, there is a noticable slowness in loading (can be seen as worm takes a while to cross the screen):

      This could be the result of the search api slowness (being addressed) or perhaps static resource inefficiencies: https://issues.jenkins-ci.org/browse/JENKINS-38253

      Investigating the causes of this (to confirm those other tickets) makes sense.

        Attachments

          Issue Links

            Activity

            Hide
            michaelneale Michael Neale added a comment -

            Keith Zantow if you could also take a look at https://issues.jenkins-ci.org/browse/JENKINS-38253 to help tom out, that would be appreciated.

            Show
            michaelneale Michael Neale added a comment - Keith Zantow if you could also take a look at https://issues.jenkins-ci.org/browse/JENKINS-38253 to help tom out, that would be appreciated.
            Hide
            kzantow Keith Zantow added a comment - - edited

            Michael Neale I looked at this last week, the issue is mostly due to the API times. After some discussion with Vivek Pandey fetching all the data using the traditional Jenkins object model results in reading a lot of data from disk, potentially including all the runs for all the jobs and more to find the latest and branch count, etc.. At a minimum, we can restrict it to the page asked for, ideally we can use some other optimizations to speed it up significantly more.

            Show
            kzantow Keith Zantow added a comment - - edited Michael Neale I looked at this last week, the issue is mostly due to the API times. After some discussion with Vivek Pandey fetching all the data using the traditional Jenkins object model results in reading a lot of data from disk, potentially including all the runs for all the jobs and more to find the latest and branch count, etc.. At a minimum, we can restrict it to the page asked for, ideally we can use some other optimizations to speed it up significantly more.
            Hide
            michaelneale Michael Neale added a comment -

            Keith Zantow good to know, yes I suspected.

            Maybe shoudl leave this open as a place holder for any other investiation related to JENKINS-38253

            Show
            michaelneale Michael Neale added a comment - Keith Zantow good to know, yes I suspected. Maybe shoudl leave this open as a place holder for any other investiation related to JENKINS-38253
            Hide
            michaelneale Michael Neale added a comment -

            Keith Zantow as shown by Vivek, the slowness at least in the case of dogfood is NOT due to search and fetching of data from disk

            Show
            michaelneale Michael Neale added a comment - Keith Zantow as shown by Vivek, the slowness at least in the case of dogfood is NOT due to search and fetching of data from disk
            Hide
            michaelneale Michael Neale added a comment -

            FYI the specific slowness that seems to impact is the last 25% of the worm. I am not sure if this is still script loading or something else (I would love to know) - usually its when loading wihout the cache (but even with...)

            Show
            michaelneale Michael Neale added a comment - FYI the specific slowness that seems to impact is the last 25% of the worm. I am not sure if this is still script loading or something else (I would love to know) - usually its when loading wihout the cache (but even with...)
            Hide
            michaelneale Michael Neale added a comment -

            I also took a look, even when loading with a warm cache:

            Request URL:https://ci.blueocean.io/adjuncts/e4de3771/io/jenkins/blueocean/blueocean.js
            Request Method:GET
            Status Code:304 Not Modified
            Is still nearly a second in time - which seems excessive. Is there a way to not require the not modified - as there is no way it would be modified as the adjuuncts uri makes it unique....

            Show
            michaelneale Michael Neale added a comment - I also took a look, even when loading with a warm cache: Request URL: https://ci.blueocean.io/adjuncts/e4de3771/io/jenkins/blueocean/blueocean.js Request Method:GET Status Code:304 Not Modified Is still nearly a second in time - which seems excessive. Is there a way to not require the not modified - as there is no way it would be modified as the adjuuncts uri makes it unique....
            Hide
            kzantow Keith Zantow added a comment -

            Michael Neale yes, there's an "easy" way to optimize resources, in general, using unique urls (already done) and far future expires headers and omitting the etags.

            Show
            kzantow Keith Zantow added a comment - Michael Neale yes, there's an "easy" way to optimize resources, in general, using unique urls (already done) and far future expires headers and omitting the etags.
            Hide
            michaelneale Michael Neale added a comment -

            Keith Zantow right - https://github.com/jenkinsci/blueocean-plugin/pull/551 is a PR by tom that sets the cache headers. Will give it a try.

            Show
            michaelneale Michael Neale added a comment - Keith Zantow right - https://github.com/jenkinsci/blueocean-plugin/pull/551 is a PR by tom that sets the cache headers. Will give it a try.
            Hide
            michaelneale Michael Neale added a comment - - edited

            Here are some gifs I made to get a baseline against the roughly equivalent "classic" screen, where blue ocean isn't as snappy as it needs to be:

            1) main dashboard:
            http://www.giphy.com/gifs/26ufkjzMWkd09D4hW

            2) Activity screen:
            http://www.giphy.com/gifs/l3vR23VQ30SGdeDAc
            (this isn't exactly one to one, as blue ocean is showing across branches).

            (ie cold load time to displaying something, ANYTHING, is beyond terrible, its just dire).

            3) showing pipeline results:
            http://www.giphy.com/gifs/l0MYNT0wNlpnRmNUI
            (once again, not quite the same, but a fair comparison I think).

            The most prominent bad UX is on cold cache load of course, but I thought I should point out these others.

            Show
            michaelneale Michael Neale added a comment - - edited Here are some gifs I made to get a baseline against the roughly equivalent "classic" screen, where blue ocean isn't as snappy as it needs to be: 1) main dashboard: http://www.giphy.com/gifs/26ufkjzMWkd09D4hW 2) Activity screen: http://www.giphy.com/gifs/l3vR23VQ30SGdeDAc (this isn't exactly one to one, as blue ocean is showing across branches). (ie cold load time to displaying something, ANYTHING, is beyond terrible, its just dire). 3) showing pipeline results: http://www.giphy.com/gifs/l0MYNT0wNlpnRmNUI (once again, not quite the same, but a fair comparison I think). The most prominent bad UX is on cold cache load of course, but I thought I should point out these others.
            Hide
            tfennelly Tom FENNELLY added a comment -

            Michael Neale Setting the cache control header has eliminated the if-modified requests. Reports are that the performance has been better since. More work to do on reducing the bundle sizes (ongoing - separate ticket). Maybe ye can close this ticket now?

            Show
            tfennelly Tom FENNELLY added a comment - Michael Neale Setting the cache control header has eliminated the if-modified requests. Reports are that the performance has been better since. More work to do on reducing the bundle sizes (ongoing - separate ticket). Maybe ye can close this ticket now?
            Hide
            michaelneale Michael Neale added a comment -

            Tom FENNELLY in my screencasts above, it still hasn't improved in each case - ie classic is still faster on a remote connection.

            However, the general feel (which is mostly snappy, just not the loading) and cold loading has improved a bit, but cold loading is still quite bad.

            Will keep this open to re-check things when JENKINS-38013 is closed. Keith Zantow has marked this as in progress so will check in if he has looked at things (otherwise moving this to the backlog).

            Show
            michaelneale Michael Neale added a comment - Tom FENNELLY in my screencasts above, it still hasn't improved in each case - ie classic is still faster on a remote connection. However, the general feel (which is mostly snappy, just not the loading) and cold loading has improved a bit, but cold loading is still quite bad. Will keep this open to re-check things when JENKINS-38013 is closed. Keith Zantow has marked this as in progress so will check in if he has looked at things (otherwise moving this to the backlog).

              People

              Assignee:
              tfennelly Tom FENNELLY
              Reporter:
              michaelneale Michael Neale
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: