Details
-
Bug
-
Status: Resolved (View Workflow)
-
Critical
-
Resolution: Fixed
Description
https://gist.githubusercontent.com/jglick/de0cf09312d8fce00ab1/raw/gistfile1.txt
Every time Queue.maintain is called, which is often, for every buildable job in the queue, which could be a lot, Job.getEstimatedDurationCandidates is called. During startup this could do some work loading the last few builds, but we expect those to be held in memory thereafter. However simply finding the last successful/any build involves PeepholePermalink.resolve, which hits the disk every time, with no caching. (It claims to "cache" but this is caching via symlink, not in memory.)
While we are waiting for the disk I/O operation to complete, the Queue is locked, and lots of other threads will typically be waiting for it.
Attachments
Activity
Looking very good so far - queue is only up to 16, so it could get worse later, but no page load slowdown at all currently.
So yeah, big performance improvement on the UI - great fix, jglick! Thanks!
Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/jenkins/model/PeepholePermalink.java
core/src/test/java/jenkins/model/PeepholePermalinkTest.java
http://jenkins-ci.org/commit/jenkins/c74dc66f4e9d954b43b64ff5be83b74ebb0f3a54
Log:
[FIXED JENKINS-22822] PeepholePermalink should maintain an in-memory cache of symlinks to avoid disk I/O.
(cherry picked from commit 2ff7a905ac866aac5aea7aae0cb97ee8906b5829)
Conflicts:
changelog.html
Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/jenkins/model/PeepholePermalink.java
core/src/test/java/jenkins/model/PeepholePermalinkTest.java
http://jenkins-ci.org/commit/jenkins/2853564b2387a19893975ed6f042c3c25bf5e062
Log:
[FIXED JENKINS-22822] PeepholePermalink should maintain an in-memory cache of symlinks to avoid disk I/O.
(cherry picked from commit 2ff7a905ac866aac5aea7aae0cb97ee8906b5829)
Conflicts:
changelog.html
Compare: https://github.com/jenkinsci/jenkins/compare/f3848d2d4865...2853564b2387
Yes, please do.