Intent to Implement: Expensive Background Timer Throttling

[Alexander Timin]

Contact emails

alt...@chromium.org

Design doc

Time-based renderer task throttling

Summary

The proposed throttling operates as follows:

• Each WebView has a budget (in seconds) for running timers in background.

• A timer task is only allowed to run when the budget is non-negative.

• After a timer has executed, its run time is subtracted from the budget.

• The budget regenerates with time (at rate of 0.01 seconds per second).

Motivation

Some badly behaved pages (e.g. javascript ads and analytics scripts) consume a lot of CPU even when the tab is in the background, impacting browser performance and battery life and ruining user experience. The idea is to place a limit on how much processing resources background pages are allowed to use.

Interoperability and Compatibility Risk

Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Pages using timers to modify favicon (e.g. Gmail) and conditionally play audio (e.g. all messengers) are of a main concern. We believe that our implementation will not break this functionality (preliminary testing shows that GMail works), but might delay some notifications if the background page is using a lot of CPU time.

Another use case that can be impacted is when user opens a page, switches to another and expects former page to load in background. We mitigate this by only throttling timer tasks; other tasks such as loading tasks will continue to run unthrottled.

WICG issue.

Firefox: No public signals.

Edge: No public signals.

Safari: No public signals.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/650594

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6172836527865856

Timer throttling demo: https://fiddle.jshell.net/vvL0e9x3/show/light/

Requesting approval to ship?

No

[Majid Valipour]

> Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Do you have any concerns if this can lead those badly behaving scripts to start playing audio to work around this restriction? (The audio may potentially be created with a low enough gain to avoid detection by user, here is my quick demo). I suppose this is more of a concern if these background tasks are important to the script and there is no other (better?) alternative to them.

Majid

[ben.m...@gmail.com]

- It'd be really helpful for a site to be able to have some sort of insight about if they are being throttled or not. If a site is being throttled they may want to investigate the cause of their CPU utilization. I'd really hate to see this shipped without some sort of debuggability.

- What initial budget will a site get? It'd be helpful to give sites a generous budget of timer CPU time when the user first switches away. A user might be multi-tasking (and want to switch to and from the tab). Also if a user opens a tab in the background throttling timers right way could fundamentally alter the loading behavior of some sites.

- Could setTimeout(0) be excluded from this, as long as the task that does the setTimeout is not itself a timer? Often times sites use setTimeout(0) to run a task in the next cycle of the event loop or as part of an abstraction.

[Alexander Timin]

On 27 September 2016 at 19:15, Majid Valipour <maj...@chromium.org> wrote:

> Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Do you have any concerns if this can lead those badly behaving scripts to start playing audio to work around this restriction? (The audio may potentially be created with a low enough gain to avoid detection by user, here is my quick demo). I suppose this is more of a concern if these background tasks are important to the script and there is no other (better?) alternative to them.

I don't think that it's going to be a big problem — one reason that is user can see that a background tab is playing music and close offending tab. But thank for your concern, I'll consider adding a metric to measure this and we will act if we detect that bad scripts are intentionally doing it on a large scale.

And there is an alternative — Service Workers. They should be the way to do things in background and UI thread is supposed to be for UI (which means it is not needed in background).

Alexander

[Alexander Timin]

Thanks, you've made very good points here!

On 27 September 2016 at 19:28, <ben.m...@gmail.com> wrote:

- It'd be really helpful for a site to be able to have some sort of insight about if they are being throttled or not. If a site is being throttled they may want to investigate the cause of their CPU utilization. I'd really hate to see this shipped without some sort of debuggability.

Informing developers that they are throttled are one of our top priorities. Currently we are going to do two things do achieve that:

- Adding detailed information about throttling to traces, so it's easy to understand why and how a site is throttled.

- Writing a console.log message when site is throttled. (Exact details are to be discussed).

 

- What initial budget will a site get? It'd be helpful to give sites a generous budget of timer CPU time when the user first switches away. A user might be multi-tasking (and want to switch to and from the tab). Also if a user opens a tab in the background throttling timers right way could fundamentally alter the loading behavior of some sites.

Yes, we want to make sure that this use case is unaffected. Two main ideas here are:

- Do not throttle page for some time after it's backgrounded (15 seconds?).

- Set a generous initial time budget (several seconds? Main load is expected to be on loading task queues, not timer task queues).

Exact solution and parameters are to be determined after experimenting and collecting metrics from the Web. 

 

- Could setTimeout(0) be excluded from this, as long as the task that does the setTimeout is not itself a timer? Often times sites use setTimeout(0) to run a task in the next cycle of the event loop or as part of an abstraction.

A very interesting suggestion which needs more consideration. I'd like to mention that in Chrome setTimeout(0) in fact is setTimeout(1).

[Ben Maurer]

On 27 September 2016 at 19:28, <ben.m...@gmail.com> wrote:

- It'd be really helpful for a site to be able to have some sort of insight about if they are being throttled or not. If a site is being throttled they may want to investigate the cause of their CPU utilization. I'd really hate to see this shipped without some sort of debuggability.

Informing developers that they are throttled are one of our top priorities. Currently we are going to do two things do achieve that:

- Adding detailed information about throttling to traces, so it's easy to understand why and how a site is throttled.

- Writing a console.log message when site is throttled. (Exact details are to be discussed).

I think that some sort of programmatic notification is also really important so that a developer can realize in aggregate how much throttling is an issue.

 

- What initial budget will a site get? It'd be helpful to give sites a generous budget of timer CPU time when the user first switches away. A user might be multi-tasking (and want to switch to and from the tab). Also if a user opens a tab in the background throttling timers right way could fundamentally alter the loading behavior of some sites.

Yes, we want to make sure that this use case is unaffected. Two main ideas here are:

- Do not throttle page for some time after it's backgrounded (15 seconds?).

- Set a generous initial time budget (several seconds? Main load is expected to be on loading task queues, not timer task queues).

Sometimes timers end up getting used early in the page life cycle (eg in FB as part of installing chat). I'd want to make sure that throttling doesn't distort the behavior or reorder timers WRT non-timer events.

 

Exact solution and parameters are to be determined after experimenting and collecting metrics from the Web.

Are you guys planning to dark launch this before enforcing?

-b

 

[Sami Kyostila]

ti 27. syyskuuta 2016 klo 21.43 Ben Maurer <ben.m...@gmail.com> kirjoitti:

On 27 September 2016 at 19:28, <ben.m...@gmail.com> wrote:

- It'd be really helpful for a site to be able to have some sort of insight about if they are being throttled or not. If a site is being throttled they may want to investigate the cause of their CPU utilization. I'd really hate to see this shipped without some sort of debuggability.

Informing developers that they are throttled are one of our top priorities. Currently we are going to do two things do achieve that:

- Adding detailed information about throttling to traces, so it's easy to understand why and how a site is throttled.

- Writing a console.log message when site is throttled. (Exact details are to be discussed).

I think that some sort of programmatic notification is also really important so that a developer can realize in aggregate how much throttling is an issue.

I think we're open to suggestions what this API could look like (PerformanceObserver-based perhaps?), but I just wanted to mention that developers can measure the lateness of their timer callbacks to observe the effect of throttling.

 

 

- What initial budget will a site get? It'd be helpful to give sites a generous budget of timer CPU time when the user first switches away. A user might be multi-tasking (and want to switch to and from the tab). Also if a user opens a tab in the background throttling timers right way could fundamentally alter the loading behavior of some sites.

Yes, we want to make sure that this use case is unaffected. Two main ideas here are:

- Do not throttle page for some time after it's backgrounded (15 seconds?).

- Set a generous initial time budget (several seconds? Main load is expected to be on loading task queues, not timer task queues).

Sometimes timers end up getting used early in the page life cycle (eg in FB as part of installing chat). I'd want to make sure that throttling doesn't distort the behavior or reorder timers WRT non-timer events.

Note that timers in background tabs are already being throttled to 1 Hz in most browsers, so this type of reordering has been happening for a good while.

 

 

Exact solution and parameters are to be determined after experimenting and collecting metrics from the Web.

Are you guys planning to dark launch this before enforcing?

As in measuring-but-not-enforcing? We've kind of already done that based on UMA data, but I think we'll still need to figure out the exact launch plan -- this is just an intent to implement :)

 

-b

- Sami

 

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Harald Alvestrand]

Will timers that aren't run be delayed or aborted? If delayed, the effect should be the same as when running on a host with 0.01 times the country speed - if aborted, correctness will suffer in more cases.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alexander Timin]

On 28 September 2016 at 19:16, 'Harald Alvestrand' via blink-dev <blin...@chromium.org> wrote:

Will timers that aren't run be delayed or aborted? If delayed, the effect should be the same as when running on a host with 0.01 times the country speed - if aborted, correctness will suffer in more cases.

Timers will be delayed — we do not cancel any timers due to correctness reasons. 

[vi...@useloom.com]

How will this affect the background pages of Chrome extensions? Or will it not affect those at all?

[rob...@hometeamcare.com]

I would love it if there was a way to override this for particular tabs, or globally to turn it off. I work at a business that has an internal web app that requires periodically polling an endpoint. This may quickly exceed 1% of the CPU time in the background, and I'd love to be able to just instruct our employees to disable throttling for our internal app.

On Tuesday, September 27, 2016 at 10:41:50 AM UTC-7, Alexander Timin wrote:

[andre...@airts.co.uk]

We're in a similar situation to Rob - we develop apps exclusively for internal corporate use and they make heavy use of websockets.  These are always running on desk-based machines (so battery life is a non-issue).

It would be very useful to have some administrative control, so that the default behaviour could be overridden or at least the budget for certain domains could be increased.

Otherwise this well-intentioned concept will be creating a lot more problems for us than it will be solving.

Regards

Andrew

[bytec...@gmail.com]

> Do you have any concerns if this can lead those badly behaving scripts to start playing audio to work around this restriction?  

I don't think that it's going to be a big problem — one reason that is user can see that a background tab is playing music and close offending tab.

I can't speak for Chromium, but I believe Chrome itself only shows the "audio playing" UI if the audio source's volume is above some threshold. When watching videos with quiet parts, I've seen the loudspeaker icon fade out. I could be mistaken, though.

[razie...@gmail.com]

Then start writing properly optimized code...

[Alexander Timin]

Chrome extensions are not affected.

[Vinay Hiremath]

Awesome! Thanks for the clarification.

[rohan...@gmail.com]

Hi,

I would like to run with more aggressive background throttling not less, but I am willing to turn it on manually. I would like a Chrome preference or plugin to throttle and renice all background tabs (including those with websockets and possibly audio) and let me unthrottle the ones that are important to me by right clicking on the appropriate tab in the Chrome Task Manager, or by right clicking on the tab's name in the top of the window.

I would be interested in comparing my CPU usage this way to what I get when I run The Great Suspender.

Thanks,

-rohan

On Tuesday, September 27, 2016 at 10:41:50 AM UTC-7, Alexander Timin wrote:

[vin...@logic-square.com]

Would it make sense to provide 3 options to the users

a) Power Save Mode (throttling as proposed)

b) Best Performance Mode (new feature turned off)

c) Custom (selective throttling - users can add exceptions etc.)