-
Bug
-
Resolution: Fixed
-
Major
LastFailureColumn, shown by default in AllView, is calling Job.getLastFailedBuild which then keeps on loading builds until it finds a failed build, with no cutoff. The fix for that would be to either impose a maximum number of builds to search back from (10? 20?); or do the search asynchronously after the page loads, which might still put some load on the server but would at least not stop you from browsing.
The same would apply to the last success column if all your recent builds failed, etc.
- depends on
-
JENKINS-18846 New lazy loading permalinks can break job.lastStableBuild != null => job.lastSuccessfulBuild != null
-
- Resolved
-
- is blocking
-
JENKINS-16023 Lazy loading causes massive delays after a period of inactivity when loading dashboard
-
- Resolved
-
-
JENKINS-8754 ROADMAP: Improve Start-up Time
-
- Closed
-
- is related to
-
JENKINS-17449 Jenkins 1.509 has different behaviour with symlink handling of e.g. lastSuccessful
-
- Resolved
-
I did a little bit more experimentation here, using it to fix the "slow People view" problem that was mentioned on the mailing list:
I now persist the cache (not a true LRU persistent cache, but I think it's a good start without external dependencies); I've switched to requiring cache objects to be Serializable:
https://github.com/justinsb/jenkins/commit/a1c68a1156be0dfa1b6c95578cd0675fa50c8fea
I use the cache to store People, using the same memoize-per-build and incremental update approach:
https://github.com/justinsb/jenkins/commit/a0ae671785ae96e1c85274332d54effe80bc875d
So as to avoid behavioural changes, rather than trying to persist the UserInfo object, instead it stores a reference to the build from which the UserInfo should be loaded. That build still needs to be loaded, but it's only the required builds. If we could persist the UserInfo safely, we could avoid this as well.