Intent to Implement and Ship: Throttling background dedicated workers

[Alexander Timin]

Contact emails

alt...@chromium.org, elle...@chromium.org

Design doc

Design doc

Summary

This intervention expands the concept of background throttling from javascript timers to dedicated workers.

Motivation

When a renderer is backgrounded, the amount of work coming from dedicated workers is higher than that coming from the main thread. This intervention aims to lessen the adverse performance and battery impact caused by content users cannot see. This intervention also addresses the recent rise of malicious scripts performing power-heavy computations without user permission (e.g. cryptocurrency mining).

Risks

Interoperability and Compatibility

Medium risk. There are web applications (i.e. SETI-at-home) which will require a user-initiated action to remain unthrottled, but the vast majority of pages should not be affected.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Mixed signals

Ergonomics

N/A

Activation

None required.

Debuggability

Similar to existing throttling mechanisms -- a console warning will be generated when worker is throttled. Tracing coverage will be provided.

Also there is a effort underway to expose throttling state as a part of chrome://discards, but given that this throttling intervention is very similar to main thread throttling, the intervention won’t be blocked on it.

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

Yes.

Is this feature fully tested by web-platform-tests?

N/A, as this is an intervention.

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes, using experiment-based rollout. The findings of this rollout will be shared on this thread.

[Ben Kelly]

On Wed, Feb 7, 2018 at 8:31 AM, Alexander Timin <alt...@chromium.org> wrote:

Firefox: No signals

FWIW, we hope to do the same in firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1401628

[Wez]

Can you provide more detail on the implementation for this?  The existing main-thread throttler appears to be design only for use by the Inspector, not for production CPU throttling, e.g. it spins on a dedicated thread on Windows, to get the desired timing precision.  (Or perhaps I'm just looking at the wrong class :)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALHg4n%3DF2sV-5bv568sahLQGKDPpqCeS%3DA2wOzPhdEeH899QnA%40mail.gmail.com.

[Alexander Timin]

On 8 February 2018 at 03:12, Wez <w...@chromium.org> wrote:

Can you provide more detail on the implementation for this?  The existing main-thread throttler appears to be design only for use by the Inspector, not for production CPU throttling, e.g. it spins on a dedicated thread on Windows, to get the desired timing precision.  (Or perhaps I'm just looking at the wrong class :)

The class implementing existing main thread throttling mechanism is TaskQueueThrottler. It throttled tasks by delaying new ones and does not interfere with running ones.

However, given that a script can hijack a worker thread completely, it's suggested to throttle long-running tasks. The implementation details of this are not finalised and two options are considered: a) modify ThreadCPUThrottler to support this use case (i.e. lose extra precision and avoid busy-wait) and suspend thread on os level b) yield control back to the scheduler inside v8 safepoints. 

[est...@chromium.org]

Is there somewhere I can read more about the user-initiated action for opting out? Where will that setting live and what will it look like?

[Ojan Vafai]

Shipping this doesn't block on the user opt-out, right?

This seems like a natural extension of the throttling we do for main thread script, so I think doesn't have substantially different implications for the platform on top of what we already ship. LGTM1 with or without the user opt-out.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9cec492c-4d18-4fa9-8d75-9ec2c1fae329%40chromium.org.

[Philip Jägenstedt]

On "Web developers: Mixed signals", are there cases other than the mentioned SETI-at-home that are known to be impacted, and have any web developers been concerned about this?

Even if we already throttle the main thread, closing the last way of doing heavy background computation (if this is the last) does change the platform I'd argue, so I'm also very curious about how sites will be able to get this capability back.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTtvvFoxuZpYOxGEtAtmwg-aD1dxbm__chetz3%2BMf9cWaA%40mail.gmail.com.

[Alex Russell]

Hey all,

Per today's API Owners meeting, a few questions following on from Philip's:

• Do we understand the percentage of content that will be impacted? Do we know of sites other than SETI that are impacted?
• Will this policy be applied to WASM content (which is conceptually identical)?
• Will UMA be logged about how frequently this is invoked?
• Have we considered launching a monitoring version of this to collect data before actually shipping?
• Will this be Finch'd?

Regards

[Ojan Vafai]

On Thu, Mar 1, 2018 at 10:52 AM Alex Russell <sligh...@google.com> wrote:

Hey all,

Per today's API Owners meeting, a few questions following on from Philip's:

• Do we understand the percentage of content that will be impacted? Do we know of sites other than SETI that are impacted?
• Will this policy be applied to WASM content (which is conceptually identical)?
• Will UMA be logged about how frequently this is invoked?
• Have we considered launching a monitoring version of this to collect data before actually shipping?

I don't think we should do this for a few reasons:

• This is unlikely to give us useful information about breakage. Our experience with throttling the main thread is that the (rare) breakage information really only came from shipping and waiting for bug reports to come in.
• This would delay shipping by 6-12 weeks at a minimum, which is not appropriate for the urgency of this change given the user impact it's mitigating. It may be the case that we try to ship, find breakage that we believe to be unacceptable and keep iterating anyways, but this would add a delay on top of that.

[Alex Russell]

TL;DR: changing my response to "LGTM".

Detail:

Spoke offline with Ojan offline and he was able to clear up what, in retrospect, turned out to be my confusion (thanks Ojan!)

I was under the impression that this was about throttling workers in foreground tabs. This isn't the proposal -- instead, what's being suggested is extending the throttling we already do to background pages to the workers created by them. 

This seems much less challenging. To some degree, it's surprising we aren't already doing this!

There's a large open question about UI and API that might be eventually created for exceptions to this throttling (to handle the SETI case), but I'm fine with this being out of scope for now.

I would like to see UMA added to understand how frequently we invoke this intervention as we build/ship it to inform that design process.

Thanks again.

[bradn...@chromium.org]

In general, sounds like a reasonable approach especially to mitigate what we're seeing now.

However, a few concerns:

* Various polyfills in JS + Wasm for decoding audio / video exist, used by Wikipedia and other. Is there any danger this could throttle these down below usability when the user wants background audio?

   - Could we use audio as a signal to permit this?

   - Would folks then play null audio to game this?

* Having a user prompt for background tasks like SETI or other user intended background work (compilers, rendering, long running simulation etc.) Is there any standards work in place to provide this? (Or did we imagine we could glean this from CPU use?)

* Once SharedArrayBuffer returns to the platform, event loop based throttling won't work for content that uses SABs to route data. How quickly can we start something OS level?

[Kentaro Hara]

Non-owner LGTM to experimenting this idea and collecting UMA.

Existing UMA shows that 43% of the CPU performance on background tabs is consumed by dedicated workers. From the perspective of "throttling invisible work", throttling workers on background tabs is super important :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6d361aef-e850-42ea-bf79-0b310fececc3%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

[Daniel Bratell]

I'm wondering if wasm will be throttled as well? The suggested throttling is aggressive (triggering after 10 seconds) and I can see how that can cause issues with for instance a chess site such as lichess.org.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jybHyW9sWOUqdMtXmnMRHdFt13YZRWQaOM4Ysw-SjrjGw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Ojan Vafai]

This throttling is only for background tabs. lichess.org would be fine if throttled in background tabs (WASM or not), no?

[Daniel Bratell]

Having a computer analyze a position for a long time is a common use case for a chess engine, but lichess wasm is a factor slower than native implementations (still impressively fast) so maybe that is something that should not be done in a browser.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTvTgxOEnUE-O7MCBa1w8VvKxQTWz5LOQ0Wg%2Bxk7dezeFg%40mail.gmail.com.

[Yoav Weiss]

On Thu, Mar 8, 2018 at 1:29 PM Daniel Bratell <bra...@opera.com> wrote:

Having a computer analyze a position for a long time is a common use case for a chess engine, but lichess wasm is a factor slower than native implementations (still impressively fast) so maybe that is something that should not be done in a browser.

Or maybe something that could use the eventual opt-in that will enable such background work to take place.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zfj4zei8rbppqq%40cicero2.linkoping.osa.

[Rick Byers]

Discussed at the API owners meeting (chrishtr@, slightlyoff@, yoav@, jochen@, rbyers@ present).  We agreed that this is largely about aligning with our existing background tab throttling policies.

There's some new compat risk here (since code running in a worker is often designed specifically to be "background work").  But our understanding is that a user opt-out for "allow unrestricted background work" is imminent. Having a user opt-out mitigates the additional compat risk.

So LGTM3 from the group if we can block shipping this change on the availability of some user opt-out.

If the UI for a user opt-out becomes stalled, then feel free to circle back on this thread and we can discuss options for other mitigations that don't require blocking on it.

/Daniel

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jybHyW9sWOUqdMtXmnMRHdFt13YZRWQaOM4Ysw-SjrjGw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTvTgxOEnUE-O7MCBa1w8VvKxQTWz5LOQ0Wg%2Bxk7dezeFg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zfj4zei8rbppqq%40cicero2.linkoping.osa.

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgPPfcfj4Yr8cmQKLukAp-0S7dBEx%3D79tn8bycVgaQctw%40mail.gmail.com.

[Alexander Timin]

Thanks for the approval!

Once again, we'll treat pages playing audible audio (or pages which recently played audible audio) are foregrounded, exactly the same as we do for main thread throttling.

I'll add metrics to record the frequency of this intervention.

I will update this thread once we launch this intervention to Dev channel and get back some numbers.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_GObw9Yd4kV2zHcBT9gGOX0iQgC%2B4T73YJK2mjkzTOJA%40mail.gmail.com.

[Daniel Bratell]

This might have the interesting side effect that a processing background script has to give the user an audible ping every now and then. I don't think that is a bad thing.

/Daniel

/Daniel

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jybHyW9sWOUqdMtXmnMRHdFt13YZRWQaOM4Ysw-SjrjGw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTvTgxOEnUE-O7MCBa1w8VvKxQTWz5LOQ0Wg%2Bxk7dezeFg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zfj4zei8rbppqq%40cicero2.linkoping.osa.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgPPfcfj4Yr8cmQKLukAp-0S7dBEx%3D79tn8bycVgaQctw%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_GObw9Yd4kV2zHcBT9gGOX0iQgC%2B4T73YJK2mjkzTOJA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Alexander Timin]

A quick update on this: I've launched the initial version to Canary&Dev and the results are really promising: -30% of background renderer process CPU usage, -10% overall renderer process CPU usage on Windows. There is also a noticeable improvement on foreground tabs both on desktop and on Android in FCP and scroll latency, of around 5-10%.

The next step is to add an opt-out and ship it :) The plan is to have Origin-Trial opt-out, here is the first draft. I'll be sending Intent-to-Experiment for the opt-out to this list shortly.

Alexander