Investigate delayed execution of bricks in resource-starved browsers

[fregante]

Extracted from https://www.notion.so/pixiebrix/1616f10d218a480daef33c9daf5d19b5?v=04fca6e992154de0af71244552114961&p=2b5ac55c820f4c4e80deca015abe10d4&pm=s

• Detect and report long-running synchronous tasks in the background page (e.g. report setInterval delta if it's delayed substantially)
• Log retries:
  • Dispatch events on retries webext-messenger#152

Where/how should we report this data? Where are non-error events reported?

[fregante]

@twschiller I need some ideas on how to deal with the results of this experiment. Since we don't have access to the runtime, we can't know which part of the code actually slowed us down. This means we'd only have a log that looks like:

• 5:40:20 400ms task
• 11:01:59 800ms task

Is that useful? Maybe it can be used as aggregated data to detect slowdowns of the product over time, but it might just be noise and we probably don't have a dashboard to track this.

Maybe we should report the specific messages, as part of the messenger itself, e.g.

• 5:40:20 COLLECT_DATA message took 1000ms, {broadcast:true}
• 5:41:01 COLLECT_DATA message took 200ms, {tab: 123}
• 11:01:59 ADD_TO_SPREADSHEET message took 300ms, {tab: 123}

My best guess is that slowdowns happen when the user has a lot of tabs open, which since #5899 can be a lot. Maybe it's best to focus on that specific issue

[twschiller]

A challenge is that some of the messages (e.g., ADD_TO_SPREADSHEET) call remote APIs. So if we naively track total execution time, we'll get false-positive warnings

Thoughts on performance metrics:

• We can add meta-data to the message itself to track the time in messenger vs. handler (with send/receipt/etc. timestamps before delegating to the handler)
• I'm not sure of a way to trace synchronous execution time of background handlers. (In a real application, you'd use a sampling profiler; even if that's available in Chrome for background pages, we wouldn't be able to use that for logging)

Other complicating factors for low-resource browsers:

• When resources are low, Chrome will put unused tabs to sleep, which presumably would also cause the messenger not to respond (and therefore retry): https://blog.google/products/chrome/new-chrome-features-to-save-battery-and-make-browsing-smoother/. From a broadcast perspective, I think it's OK not to provide responses from these. Otherwise, we'd somehow have to revive the tab. Are these tabs discarded or a different state?

Brainstorming here:

• One approach is having the background page ping tabs for liveness. If we have evidence that a tab is asleep/unavailable, we could limit retries to that tab

Maybe we should report the specific messages, as part of the messenger itself, e.g.

Agree that could be helpful

cc @BLoe @grahamlangford

[fregante]

I opened:

• Track timing webext-messenger#175

I'll finalize:

• Dispatch events on retries webext-messenger#152

As for the discarded tabs:

• The extension now ignores them in broadcasts
  • Deal with discarded tabs #6624
• The messenger treats them as closed tabs
  • Don't retry on discarded tabs webext-messenger#163

Discarded tabs are essentially closed. When revived, they even get a new tab ID. The onUpdated event fires with {discarded: false} but it doesn't update the tab ID.

This last piece of information was found when working on fregante/webext-inject-on-install#3

---

I'm tentatively closing this issue. Feel free to reopen or create a more specific one, if one isn't already open.