Bug 214821 – [ews] Speed up ews status bubble loading speed

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Aakash Jain]

We should speed up ews status bubble loading speed. 

In the last year we have added many new queues to EWS (e.g.: tvOS, watchOS, services, api-gtk etc.). The loading speed of the status-bubbles on Bugzilla have seems to be slowed down. We should try to speed it up.

[Radar WebKit Bug Importer]

<rdar://problem/66157506>

[Kenneth Russell]

When loading individual bugs on bugs.webkit.org, the Chrome browser at least often shows the spinner forever, because the iframe to ews.webkit.org never completes loading.

Would it be possible to rephrase the code of that iframe so it issues explicit Fetch calls for the status of each bubble, or similar? My best guess is that it's loading a bunch of declaratively-specified resources and that's why the browser thinks the loading of the iframe never completes.

[Aakash Jain]

The portion to calculate the patch position in queue seems to be slow. Therefore, soon after a patch is uploaded (and when patch is in waiting in queue on various builders), it takes much longer to load all the bubbles. After the builds have started, bubbles load relatively quickly. The position in queue calculation logic needs to be optimized.

[Aakash Jain]

Created attachment 413501 [details]
Patch

[EWS]

Committed r269555: <https://trac.webkit.org/changeset/269555>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 413501 [details].

[Aakash Jain]

Keeping this bug open since we might need more improvements to status-bubble loading time.

[Aakash Jain]

We noticed significant slowness in ews status-bubble loading today in rdar://78819436, since queue position calculation was slow. It was slow since there were extremely large number of builds on a JSC queue yesterday (due to a bot being in bad state and continuously retrying builds).

[Aakash Jain]

Created attachment 430493 [details]
Patch

[Aakash Jain]

(In reply to Aakash Jain from comment #8)
> Created attachment 430493 [details]
> Patch

This change does a trade-off between accuracy of queue position vs status-bubble loading time. This would reduce the calculations needed for queue position computation, but the position might not be accurate if the queue has a backlog of more than 12 hours (which shouldn't be the case normally). If the backlog is less than 12 hours, then the queue position will be accurate.

Also, this patch separates the logic of when to hide the status-bubble. Status-bubble will now be hidden after 7 days of no build. However, if patch is waiting for more than 12 hours, but less than 7 days, instead of computing the exact queue position, we display a fixed queue position.

[Aakash Jain]

Created attachment 430506 [details]
Patch

[Aakash Jain]

(In reply to Aakash Jain from comment #10)
> Created attachment 430506 [details]
> Patch
Not displaying any queue position when we skip calculating the position (just white status-bubble). Also, for CANCELLED/SKIPPED builds, strike-through the status-bubble.

[EWS]

Committed r278455 (238475@main): <https://commits.webkit.org/238475@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 430506 [details].

[Aakash Jain]

Deployed the change on the server.