-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
CentOS 7
Jenkins v1.642.4
Sectioned View Plugin v1.20
Jenkins views of type Sectioned View are much slower to load than the standard views even for trivial cases. In our most simple test case we created a sectioned view with a single section which displays a list of jobs based on a regular expression to which we use ".*" to display every job. When comparing the load times of this test view against the default "all" view, the former takes approximately 25s on average to load where as the latter takes less than 4 seconds to load. Also for comparison I created a new basic list view and configured the same regular expression to display all available jobs and the load time was comparable to the "all" view. So in this test case the sectioned view was over 6 times slower to load than the comparables.
Further, if one creates multiple sections in the sectioned view the performance decreases even further, with load times reaching in excess of 1-2 minutes in some of our test cases. In extreme cases such views even time out because the load times are so slow.
As another test case I tried restricting the sectioned view so the section(s) had a more restrictive regular expression so only a small subset of all of our available jobs are being displayed (ie: a few dozen matches instead of a few thousand). This seemed to have no appreciable effect, which seems to suggest the issue is somehow associated with the section filters and not the number of jobs matched by the filter.
If anyone has any suggestions on what might be causing this slow down feel free to let me know, however thus far it would appear there is some unique behavior to job filters applied to a sectioned view that make it much less efficient than the built in list views and thus may be a bug with the sectioned view plugin that needs to be fixed.
NOTE: We do have quite a few plugins installed in our Jenkins instance, but to try and minimize the impact of the other plugins I have configured our test views to only display a single column in each view which displays the name of the job (ie: excluding columns that may need to access build history and such, like the weather column, the build status column, etc.) and the results are pretty much consistent.