Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
-
Blue Ocean 1.5 - beta 3
Description
During FOSDEM discussion about a problem we had with BlueOcean being prohibitively slow, a reasonable guess from markwaite was that our system in question stores a long history of builds - tens of thousands of those. Indeed, when the browser sends a request for BlueOcean (main panel, particular project, a build) the server spends a lot of time (minutes) in "wait" state for one of the CPU cores while others are idle or in small user time spending.
Rendering the list of recent 50-100 builds or details of a particular build should not require inspecting all histories of all builds, right?
Attachments
Issue Links
- duplicates
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Open
-
Activity
smek
added a comment - Looks like pull requests are merged. But I find it still a lot slower compared to normal pipeline view, when I open up a job.
smek
added a comment - Looks like pull requests are merged. But I find it still a lot slower compared to normal pipeline view, when I open up a job. 
Brian J Murrell
added a comment - We are fully up to date with Jenkins and plugins and Blue Ocean is still terrible to have to sit and wait through all of the stuff it loads.
Brian J Murrell
added a comment - We are fully up to date with Jenkins and plugins and Blue Ocean is still terrible to have to sit and wait through all of the stuff it loads. 
Michał Woś
added a comment - Same here. Pipeline views load acceptably fast. However job view (.../blue/organizations/jenkins/JOB-NAME/activity/) is terribly slow. We keep only last 50 builds.
Michał Woś
added a comment - Same here. Pipeline views load acceptably fast. However job view (.../blue/organizations/jenkins/JOB-NAME/activity/) is terribly slow. We keep only last 50 builds. I have a theory about why Blue Ocean page loads can seem so slow. If you look at the last, 3rd last (the highlighted one), 4th last and 7th last items in: 
you can see that it takes 30s (yes, 30 seconds!). Every Blue Ocean page load does this, AFAICT. It seems to be some kind of GET that is meant to take 30s for some reason.
The problem with this kind of behaviour by the (Jenkins web) server is that modern browsers limit the number of sockets (6 for Chrome, IIRC) that are allowed to be open to any single server. When you have a page that ties up a socket for 30s, repeatedly in a "live refresh" (i.e. AJAX) type of web page it doesn't take too many tabs open to Blue Ocean pages to tie up all of the limited number of sockets the browser will open to a server with these 30s page loads. All other fetches to the Jenkins server then block waiting for one of these sockets to come out of their 30 GET.
This can be seen by going to a Classic View Jenkins page and watching the status bar on the lower right on Chrome saying that it's waiting for available sockets. I get that very frequently when I have a number of open Blue Ocean pages. And it goes away as I close down the number of open Blue Ocean pages.
Having a limit on the number of open Blue Ocean pages should NOT be considered the solution to this problem.
Brian J Murrell
added a comment - - edited I have a theory about why Blue Ocean page loads can seem so slow. If you look at the last, 3rd last (the highlighted one), 4th last and 7th last items in: you can see that it takes 30s (yes, 30 seconds!). Every Blue Ocean page load does this, AFAICT. It seems to be some kind of GET that is meant to take 30s for some reason.
The problem with this kind of behaviour by the (Jenkins web) server is that modern browsers limit the number of sockets (6 for Chrome, IIRC) that are allowed to be open to any single server. When you have a page that ties up a socket for 30s, repeatedly in a "live refresh" (i.e. AJAX) type of web page it doesn't take too many tabs open to Blue Ocean pages to tie up all of the limited number of sockets the browser will open to a server with these 30s page loads. All other fetches to the Jenkins server then block waiting for one of these sockets to come out of their 30 GET .
This can be seen by going to a Classic View Jenkins page and watching the status bar on the lower right on Chrome saying that it's waiting for available sockets. I get that very frequently when I have a number of open Blue Ocean pages. And it goes away as I close down the number of open Blue Ocean pages.
Having a limit on the number of open Blue Ocean pages should NOT be considered the solution to this problem.
I looked at the attached HAR file. Most slowness are around how favorites are pre-fetched and loaded subsequently.
Fixes for optimized favorites loading (https://github.com/jenkinsci/blueocean-plugin/pull/1638) and minimizing returns in latestRun in pipeline should fixed this issue (https://github.com/jenkinsci/blueocean-plugin/pull/1635).
These fixes went in 1.5.0-beta-1. I recommend trying latest 1.5.0-beta-2, and report back/reopen if the problem persists.