|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
As an aside, as to why
JENKINS-23945took so long to be reported: in part because there were other even more serious lazy-loading bugs masking it for a while (such asJENKINS-18065). After that, just because you were suffering from that bug does not mean you knew that a particular graph in the corner of the job index page was thrashing the system. You may just have concluded that Jenkins did not scale well to large systems and thrown more hardware at it, or put up with five-minute page loads.That is the problem with performance/scalability bugs: people cannot clamor for fixes of problems they cannot even identify without training and tools. JENKINS-25078 is another example: once the administrator was told what the source of the problem was, and how to opt out of what was for that installation an unnecessary feature, massive performance problems suddenly vanished. So we need to strike a balance of unconditionally showing useful data only when it is cheap to compute, and somehow allowing the admin (or a browsing user) to opt in to potentially more expensive but thorough reports in a way that makes the tradeoff clear.
(And of course in the longer term we need to find a way of storing build records that makes display of routine metadata actually be cheap.)