• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • blueocean-plugin
    • None
    • Firefox 52.1.2 on OS X
    • Blue Ocean 1.2-beta1, Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta4, Blue Ocean 1.2, Blue Ocean - Candidates

      https://ci.jenkins.io/blue/organizations/jenkins/Core%2Fjenkins/pr takes 30 seconds to load

      Activity pages similarly take forever.

          [JENKINS-44867] PR tab takes forever to load

          Daniel Beck added a comment -

          Attached: Me first navigating from home page to Core/jenkins activity page, then to PRs. Takes 1.2 minutes.

          Daniel Beck added a comment - Attached: Me first navigating from home page to Core/jenkins activity page, then to PRs. Takes 1.2 minutes.

          Vivek Pandey added a comment -

          danielbeck Please open another ticket for activity perf issue.

          Vivek Pandey added a comment - danielbeck Please open another ticket for activity perf issue.

          Vivek Pandey added a comment -

          PR https://github.com/jenkinsci/blueocean-plugin/pull/1149 merged to release branch. It will be in next release, most likely 1.1.2.

          Vivek Pandey added a comment - PR https://github.com/jenkinsci/blueocean-plugin/pull/1149  merged to release branch. It will be in next release, most likely 1.1.2.

          James Dumay added a comment - - edited

          vivek as discussed we need to make io.jenkins.blueocean.rest.impl.pipeline.PipelineJobFilters#isPullRequest use SCMHeadCategory to improve the performance of this lookup.

          Any ideas on how we can do that, stephenconnolly?

          James Dumay added a comment - - edited vivek as discussed we need to make io.jenkins.blueocean.rest.impl.pipeline.PipelineJobFilters#isPullRequest use SCMHeadCategory to improve the performance of this lookup. Any ideas on how we can do that, stephenconnolly ?

          Currently you are using SCMHead.HeadByItem.findHead(item) instanceof ChangeRequestSCMHead which is reasonable, but not the intent of the API.

          The intent of the API is that you would ask the item's parent SCMSource for the SCMHeadCategory though I should point out that if the code in question is the hot path, that check would be more expensive in terms of CPU.

          You probably need to use a profiler and see where the code is hot.

          To use categories correctly, you need to ask the relevant SCMSource instances for the categories they are providing. Once you have all the potential categories, you then use SCMHeadCategory.collect to aggregate them... Each of those aggregate categories should get its own "tab" (you can consider treating the "uncategorized" category specially).

          Then for each tab, you just ask it's category if the SCMHead is a SCMHeadCategory.isMatch(SCMHead)

           

          Stephen Connolly added a comment - Currently you are using SCMHead.HeadByItem.findHead(item) instanceof ChangeRequestSCMHead which is reasonable, but not the intent of the API. The intent of the API is that you would ask the item's parent SCMSource for the SCMHeadCategory though I should point out that if the code in question is the hot path, that check would be more expensive in terms of CPU. You probably need to use a profiler and see where the code is hot. To use categories correctly, you need to ask the relevant SCMSource instances for the categories they are providing. Once you have all the potential categories, you then use SCMHeadCategory.collect  to aggregate them... Each of those aggregate categories should get its own "tab" (you can consider treating the "uncategorized" category specially). Then for each tab, you just ask it's category if the SCMHead is a SCMHeadCategory.isMatch(SCMHead)  

          If SCMHead.HeadByItem.findHead(Item) is a hot code path then there are some caching optimizations I could apply, but a brief code inspection suggests that it should not be the hot path for you.

          Stephen Connolly added a comment - If SCMHead.HeadByItem.findHead(Item) is a hot code path  then there are some caching optimizations I could apply, but a brief code inspection suggests that it should not be the hot path for you.

          Vivek Pandey added a comment - - edited

          stephenconnolly Classic uses `SCMHeadCategory` and renders it relatively quickly compared to blueocean. See https://ci.jenkins.io/job/Core/job/jenkins/view/change-requests/ vs https://ci.jenkins.io/blue/organizations/jenkins/Core%2Fjenkins/pr. That prompted us to think this might help us. I tried to run profiler but could not get consistent hot spot as creating PR based data set is not easy.

           

          In one of the profiler test this line came up, https://github.com/jenkinsci/blueocean-plugin/blob/4f595b217795096240fff6c4bbd8af1921282b18/blueocean-pipeline-api-impl/src/main/java/io/jenkins/blueocean/rest/impl/pipeline/BranchImpl.java#L54. But again it was based on the data set I was using which was not big enough to trigger proper hot spot.

           

           

          Vivek Pandey added a comment - - edited stephenconnolly  Classic uses `SCMHeadCategory` and renders it relatively quickly compared to blueocean. See https://ci.jenkins.io/job/Core/job/jenkins/view/change-requests/  vs https://ci.jenkins.io/blue/organizations/jenkins/Core%2Fjenkins/pr . That prompted us to think this might help us. I tried to run profiler but could not get consistent hot spot as creating PR based data set is not easy.   In one of the profiler test this line came up, https://github.com/jenkinsci/blueocean-plugin/blob/4f595b217795096240fff6c4bbd8af1921282b18/blueocean-pipeline-api-impl/src/main/java/io/jenkins/blueocean/rest/impl/pipeline/BranchImpl.java#L54.  But again it was based on the data set I was using which was not big enough to trigger proper hot spot.    

          James Dumay added a comment -

          Confirmed that this is still an issue

          vivek stephenconnolly did I see correctly that in the new branch source that we've got a more efficient way of searching for branches that are PRs?

          James Dumay added a comment - Confirmed that this is still an issue vivek stephenconnolly did I see correctly that in the new branch source that we've got a more efficient way of searching for branches that are PRs?

          Michael Neale added a comment -

          can anyone confirm if this is helped by 1.2/newer releases of late? I tried with link above and it seemed "ok" but there are many other variables in my link speed. 

          Michael Neale added a comment - can anyone confirm if this is helped by 1.2/newer releases of late? I tried with link above and it seemed "ok" but there are many other variables in my link speed. 

          I ran into this recently and the issue was actually failing connections to Sonarqube. Any plugins you have installed may be calling APIs for the PR builds when you load the PR tab. If those calls stall or get connection timeouts, they will block the loading of the page view. This is surely a bug since the page view should not be blocked like this, but can be resolved if you resolve the underlying problems connecting to e.g. Sonarqube.

          David Sanftenberg added a comment - I ran into this recently and the issue was actually failing connections to Sonarqube. Any plugins you have installed may be calling APIs for the PR builds when you load the PR tab. If those calls stall or get connection timeouts, they will block the loading of the page view. This is surely a bug since the page view should not be blocked like this, but can be resolved if you resolve the underlying problems connecting to e.g. Sonarqube.

            vivek Vivek Pandey
            danielbeck Daniel Beck
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: