Build History - 100s/1000s of builds - performance

Hi. I'm interested in hearing how people would feel about a change to how the BuildHistory widget handles build histories where there are 100s or 1000s of builds. As JENKINS-26445 discusses, the performance of this widget can stink if there

Re: Build History - 100s/1000s of builds - performance

On Fri, Jan 23, 2015 at 10:53 AM, Tom Fennelly wrote: > I propose changing it to support a pagination type mechanism where you get > "Prev", "Next" and "Top" buttons on the widget +1 for either pagination or ProgressiveRendering. -- You received this message because you are subscribed to the G

Re: Build History - 100s/1000s of builds - performance

+1 for pagination I know its not exactly the same thing, but maybe this could also create some ideas on how to solve an issue in the timeline widget: https://issues.jenkins-ci.org/browse/JENKINS-22008 Domi > On 23 Jan 2015, at 17:01, Jesse Glick wrote: > > On Fri, Jan 23, 2015 at 10:53 AM, To

Re: Build History - 100s/1000s of builds - performance

On Fri, Jan 23, 2015 at 11:11 AM, d...@fortysix.ch wrote: > I know its not exactly the same thing, but maybe this could also create some > ideas on how to solve an issue in the timeline widget: JENKINS-22008 I think the implementation work would be mostly unrelated. JENKINS-22008 “just” needs so

Re: Build History - 100s/1000s of builds - performance

What about the "in queue" part of the widget? I vote for moving it out into a separate widget otherwise tha pagination could get tricky if a build has been added or removed from the queue between page requests. /B On Fri, Jan 23, 2015 at 5:31 PM, Jesse Glick wrote: > On Fri, Jan 23, 2015 at 11:

Re: Build History - 100s/1000s of builds - performance

Hi Bobby. What do you mean when you talk about moving it out into a separate widget? Move which parts out? Are you saying have 2 widgets, one for in-queue/running builds and one for completed builds? Perhaps I don't know all the use case but I was thinking (as I said in the original email) tha

Re: Build History - 100s/1000s of builds - performance

Well, the algorithm for the buildhistory widget on the job page is, put simply; list all queued builds then start listing the history (that would include currently running builds iirc). So if only the history part of the list was paginated, the first page iiuc would have the queue plus X builds and

Re: Build History - 100s/1000s of builds - performance

Okay, thanks Bobby. Let me have a closer look at it to see can I come up with something that might work within a single widget. On Monday, January 26, 2015 at 10:10:50 AM UTC, Robert Sandell wrote: > > Well, the algorithm for the buildhistory widget on the job page is, put > simply; list all que

Re: Build History - 100s/1000s of builds - performance

On Mon, Jan 26, 2015 at 5:10 AM, Robert Sandell wrote: > the algorithm for the buildhistory widget on the job page is […]: > list all queued builds then start listing the history These are two distinct widgets; the job index page shows both, but a view page (for example) shows only the queue widg

Re: Build History - 100s/1000s of builds - performance

Might be slightly off topic but since we are talking about build history. I was always confused by why the most important part of the page 'build history' is tucked into a corner instead of being ( literally) front and center. Paginating that small widget in the corner would be awkward at best.

Re: Build History - 100s/1000s of builds - performance

I created PR #1641 around efforts to address the issue of huge build histories. Hopefully there'll be a CI build available soon (from CI PR builder). It's a WiP but please try it out and let us know what works, doesn't work, is missing etc -- Y