I hit this issue myself. I whipped up a quick proof-of-concept of using caching to fix:
https://github.com/justinsb/jenkins/commit/d539c6680ea1fb14f45c63ec21ecf8df046f3352
I debated caching the jobs themselves, but they're not Serializable
, so that would eliminate many of the more advanced caching solutions.
Instead, I just memoize the function results, recording against each (completed) build the build number of e.g. lastFailure. To retrieve, we walk the build chain as normal, but we can short-circuit as soon as we come across a memoized result. When we find a result, we cache it against the most recent completed build, it isn't already there. This relies on an LRU cache to expire old entries.
Currently this is only in-memory, but if we agree that caching is a good answer, I think we'd want to implement a persistent cache so that this survives across restarts. I suspect this memoization approach could well prove helpful for performance in many places in Jenkins.
I know the patch is not ready to merge
. If someone wants to take the idea and run with it, feel free; otherwise, comments/criticism welcome. If this does have broader applicability, should I post to the Jenkins-dev mail-list?
In fs jenkins have some symlinks like 'lastStable' or 'lastSuccessful'. May be good point is to create other 'last<Failure|Unstable|whatever' and use these links when load jobs in view.
Also build.xml is to heavy to parse it only for few columns displayed on page. Possibly creating an light json file with only required info also improves performance.