High fidelity progress bar is generating too many events

[osis]

The high fidelity progress bar is generating an event stream that is overloading Concourse UI.

Below is an event stream for two very similar builds that took about an hour. The first is from a month ago (low fidelity) which resulted in 30KB. The high fidelity equivalent results in 1.7MB.

Looks like the call itself takes 10 seconds to complete but the rendering takes minutes or can freeze the UI indefinitely.

[crawsible]

@Osis are you still seeing this behavior? @dannysullivan shipped a fix for this a few days ago.

[osis]

@crawsible Running a build now to check. Should take about an hour.

[osis]

27min build resulted in a 67kb event stream. So, if you 2x it you can see that it's larger than the original but still a big improvement.

Thanks for the quick turnaround!

[osis]

Eventually got a build that took over and hour.

Result was a 130KB event stream.

[dannysullivan]

@Osis We can arbitrarily reduce the fidelity of the progress bar - if you run into big problems with the number of events in the future please let us know and we can reduce it more.

[osis]

@dannysullivan I think this works out great. I'm definitely an edge case in the sense that I'm downloading almost all the tiles off of Pivotal Network.

I'll let you know if anything changes! Thanks.

[crawsible]

@Osis I could see a world in which refresh rate -- or bar on/off -- is configurable, but only if it's extremely painful. Is the current outcome after the fix just that navigating Concourse is a bit slow, or are we talking an unusable/crashing tab?

[osis]

@crawsible @dannysullivan The original 1.7MB stream was freezing the chrome process, so that was definitely showstopper.

Now we're getting into the grey area of what's tolerable so I'll show numbers so you can make a more informed decision that goes beyond my perceptions.

I just had a large amount of cache misses which replicated the scenario of the 1.7MB event stream, but now it has been reduced to 365KB, which is a big improvement. This involved downloading 37 tiles over a span of 57m 25s. Which is a lot of progress to show. 😱

Now, back to your question about UX, the 365KB event feed results in the following performance profile. This shows that while the network call is quick, the browser took 12 seconds to render the feed.

For comparison, here is the profile for a build that downloaded 1 tile over 16 minutes and resulted in a 53KB event stream. This shows that the a stream of this size took half a second to render (467ms).

I'll leave it to you to ultimately decide what's reasonable or not. 12 seconds to render anything is way too long in my opinion. At the same time, I understand that I'm an edge case and not many people are download 37 tiles at once. 😁

[mavenraven]

@vito