Bug 214821

Summary: [ews] Speed up ews status bubble loading speed
Product: WebKit Reporter: Aakash Jain <aakash_jain>
Component: Tools / TestsAssignee: Aakash Jain <aakash_jain>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, jbedard, kbr, ryanhaddad, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description Aakash Jain 2020-07-27 05:28:08 PDT
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.
Comment 1 Radar WebKit Bug Importer 2020-07-27 05:28:25 PDT
<rdar://problem/66157506>
Comment 2 Kenneth Russell 2020-09-25 17:43:48 PDT
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.
Comment 3 Aakash Jain 2020-11-06 17:09:49 PST
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.
Comment 4 Aakash Jain 2020-11-06 17:14:53 PST
Created attachment 413501 [details]
Patch
Comment 5 EWS 2020-11-06 18:09:24 PST
Committed r269555: <https://trac.webkit.org/changeset/269555>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 413501 [details].
Comment 6 Aakash Jain 2020-11-06 18:27:12 PST
Keeping this bug open since we might need more improvements to status-bubble loading time.
Comment 7 Aakash Jain 2021-06-03 12:16:07 PDT
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).
Comment 8 Aakash Jain 2021-06-03 12:29:39 PDT
Created attachment 430493 [details]
Patch
Comment 9 Aakash Jain 2021-06-03 12:39:08 PDT
(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.
Comment 10 Aakash Jain 2021-06-03 15:21:20 PDT
Created attachment 430506 [details]
Patch
Comment 11 Aakash Jain 2021-06-03 15:25:31 PDT
(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.
Comment 12 EWS 2021-06-04 07:19:24 PDT
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].
Comment 13 Aakash Jain 2021-06-04 07:39:38 PDT
Deployed the change on the server.