-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
-
Blue Ocean 1.4 - beta 3
Some users see activity screen as very slow when there are a large number of runs (this seems to be the more common and serious case...)
The best example of this is https://ci.jenkins.io/blue/organizations/jenkins/Core%2Fjenkins/activity - note how long it takes to load (compared to other pipelines there). You also see this if you open from a PR and then dismiss the result screen (as it goes back to activity) - batmat reported this.
(this seems to be slow even when anon, don't need to be logged in, but may be related to favourites too when logged in)
— NOTE ----
This ticket was split from https://issues.jenkins-ci.org/browse/JENKINS-44995
so please see the support bundles/info there as it may be relevant.
Support bundles:
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-
[JENKINS-48254] Very slow access of activity screen
bksaville seckler sbabu oz123 - tracking general slowness here.
I am having trouble making sense of the support bundles just now ("slow requests" aren't showing up in them"). If you are able to experiment then disabling the blue ocean JIRA plugin (new since 1.3) may make sense (although if you saw this with 1.2 - then disregard).
Also if you could turn on "slow requests" as an option when you generate the support bundle, would be helpful.
vivek imeredith I am seeing some stack traces like this in the support bundles (perhaps we can get one from jenkins.io to see it at a bigger scale too):
"Handling GET /mardyn/blue/rest/organizations/jenkins/pipelines/PIPE_NAME/runs/ from 0:0:0:0:0:0:0:1 : qtp997608398-19" id=19 (0x13) state=RUNNABLE cpu=92%
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.exists(File.java:819)
at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:871)
at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:843)
at hudson.model.AbstractBuild.getChangeSets(AbstractBuild.java:857)
at jenkins.scm.RunWithSCM.hasParticipant(RunWithSCM.java:146)
which implies it is our friend calcChangeSet hurting things again - this is non multi branch so isn't the multibranch activity calculation but just listing a page of runs (ci.jenkins.io DOES use multibranch on the core jenkins project, and is very slow, but may be same thing... if we can get s support core from them too may see that). More investigation needed...
imeredith is going to take a look at this from the run loading point of view...
note that https://github.com/jenkinsci/jenkins/pulls has 144 open PRs, so perhaps the # of branches/PRs could contribute to activity loading time as well as number of runs (it is hard to say)