Status: Closed (View Workflow)
When using an authorization strategy other than Unsecured or FullControlOncedoggedIn if there are 10,000+ jobs tied to labels, the tag cloud makes rendering the individual node screens seriously unresponsive as there are repeated access checks of read permission when counting the number of jobs with which to scale the tag cloud.
It is not necessary to run the permission checks in order to return the count of jobs, and additionally it is not necessary to build a list of all jobs and then sort the list before filtering and then throwing away the list and retaining the count.
A specialized count function with a denormalized loop should provide more usable performance... additionally it is questionable whether the tag cloud provides much utility for very large installations.
Is this really “minor” given that the original report claimed >60sec load time per page as a result of this? And should it be lts-candidate?
I don't know how many users have 10,000+ jobs, so far as I know Daniel was the first to identify this issue. I have no issue with upgrading to Major.
I thought a fix had to be in trunk for 2wk+ before considering for LTS. If it can be flagged as such immediately, fine by me (and presume Daniel too)
I thought a fix had to be in trunk for 2wk+ before considering for LTS.
It can be flagged at any time; the two-week rule applies to merging it.
Yes, probably the JIRA link daemon was malfunctioning at the time of commit.
Code changed in jenkins
User: Stephen Connolly
[FIXED JENKINS-18660] Added dedicated denormalized counter function
(cherry picked from commit 5981ac4ed7b4b5c462a71ae186a133f7fe44e1a1)
Integrated in jenkins_main_trunk #2699
[FIXED JENKINS-18660] Added dedicated denormalized counter function (Revision 5981ac4ed7b4b5c462a71ae186a133f7fe44e1a1)
Result = SUCCESS
Stephen Connolly : 5981ac4ed7b4b5c462a71ae186a133f7fe44e1a1