Developer communication for interventions (expensive background timer throttling)

[Rick Byers]

Hey Alex / Kenji

Forking this thread to intervention-dev for a minute to discuss the meta issue.  I don't think Chris and I ever really got a response to our questions around developer documentation here (below).  Was any work done for that at all?  I can't find this change mentioned in any of our usual breaking change blog posts, and even our chromestatus entry wasn't updated to say this was actually shipping.  

We've seen this pattern with a number of interventions.  In general I'm concerned about us making such breaking changes without clearly communicating them and guidance for them to web developers.  What can we do to ensure that we're actually following through on outreach, blog posts, status entries, etc. before shipping breaking changes?

For this specific issue I've marked the bug as ReleaseBlock-Stable suggesting we try to rush in a disable for M56 to give us more time to get caught up with the outreach / communications.

Rick

On Thu, Nov 17, 2016 at 8:04 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM3, but I agree with Rick's comments about further improvements to the rollout communication.

On Thu, Nov 17, 2016 at 7:27 AM, Rick Byers <rby...@chromium.org> wrote:

Thanks for the details.  LGTM2

A couple more minor questions inline.

On Thu, Nov 17, 2016 at 5:26 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

If WebViewImpl::setVisibilityState is the trigger, then I think web developers can simply use document.visibilityState and the related events to know when throttling may happen. To have an API to know that it has definitely happen seems nice for predictability in principle, but if aren't any known good reasons to do a lot of work on the main thread while in the background, then I'm inclined to think we should punt on that.

Rick, do you have any further concerns? LGTM1 for me.

On Thu, Nov 17, 2016 at 12:26 AM 'Yuri Wiitala' via blink-dev <blin...@chromium.org> wrote:

I think we're good to go here for tab capture:

1. There has been recent work on detecting when there is audible sound coming from the renderer, and turning off timer throttling in that case.

2. During tab capture, the captured renderer is explictly *not* told when a browser tab becomes backgrounded. Thus, a captured renderer should always behave as if it thinks it's in a foreground tab.

3. Otherwise, I think the proposal here can only improve the tab capture experience. For example, if a badly behaved page's JavaScript is eating up CPU, we want the new throttling logic to engage so that we have more CPU for capture and real-time video encoding (which will improve quality).

On Tue, Nov 15, 2016 at 4:31 PM, mark a. foltz <mfo...@chromium.org> wrote:

+miu as an FYI.  We should make sure tabs with an active content capture device are exempted as well, if they aren't already.

On Mon, Nov 14, 2016 at 4:26 PM, 'Alexander Timin' via blink-dev <blin...@chromium.org> wrote:

Background tabs on Android are suspended after 5 minutes in background. Minor improvements may happen, but major win is expected on desktops.

Background tab is the one which is not visible to the user (WebViewImpl::setVisibilityState is the source of truth); unfocused windows are considered foreground. This mechanism is the same as currently exists for background timer alignment.

So this means, for example, when we do a blog post about this we should tell users that they can always drag a tab into a new window if they don't want it to be throttled while they're working in another tab, right?  I assume we don't know when a window is occluded by some other window at the OS level (or if we do, you could always have a tiny bit peaking out to keep it considered "foreground").

Audio-playing sites are exempt from throttling (even after for some time after audio stopped playing). 

Also for your convenience I copied intervention guidelines here:

Predictability: Throttling mechanism is well-defined. High-level description (only pages with significant CPU load are going to be impacted). 

Avoidability: Heavy computations on UI thread is not best practice, so only bad-behaved pages are going to be impacted. 

Transparency: Console log message is generated when tasks we throttled for non-trivial amount of time (small throttling is not reported because we already align timers in background tabs). Also developer can monitor start time of tasks and detect intervention programmatically.

Great!  Does / will the console warning include a URL for more details (eg. at least the chromestatus entry for now, ideally a blog post)?  Can we publish a sample test page that shows this (both small throttling without a warning, and large throttling with a warning) in action to help explain what's going on?

  

Data-driven: Main UMA metric that we are monitoring is BackgroundMainThreadLoad. It is percentage of time that renderer spends executing javascript tasks. Given that >90% of pages have low CPU usage, we are expecting changes to high percentiles (95, 99), not average (95 percentile is 10% load, 99 percentile is 90% load). 

Yep, that makes perfect sense.  I was looking at the 99th percentile with Ojan last week - bringing that down will be huge!

Alexander

On 13 November 2016 at 00:02, Rick Byers <rby...@chromium.org> wrote:

I'm excited about this, thanks for working on it!

Background tabs on Android are generally 100% suspended, right?  So this is primarily a desktop feature, or is there non-trivial Android impact too?

Since this is an intervention, can you comment (probably best in the design doc) on the extent to which it will adhere to the intervention design guidelines?  Eg. how will we measure it's positive impact, will we give advice to developers for detecting when it's active in case they need to adapt / fail?  Will there be a console warning or anything to help developers understand when they're being impacted?

How exactly do you define "background"?  Eg. is the visible tab of an unfocused (even occluded) window "background"?  I'm wondering if there's any advice we can give users who want to keep some expensive app running while they're actively using another window.

I'm a little nervous about other scenarios (like background music player) that we might be breaking without realizing it.  Is there any chance it would be easy / useful to use RAPPOR to get a list of top sites that would be most impacted by this in practice, just to skim for any potentially interesting use cases (eg. video editing or other computation-heavy scenarios)?

Thanks!

   Rick

On Fri, Nov 11, 2016 at 11:40 PM, Kentaro Hara <har...@chromium.org> wrote:

Non-owner LGTM.

keishi@ and others have also confirmed that ads on background tabs are one of the largest power consumers, so the budget-based timer throttling will help a lot to save the power consumption of Chrome.

Also the budget-based timer throttling enables us to implement a background tab suspension in a better manner (i.e., we can just set the budget to a small value). The background tab suspension is a key technology of Memory Coordinator to massively drop memory from background tabs.

On Sat, Nov 12, 2016 at 4:30 AM, Alexander Timin <alt...@chromium.org> wrote:

Yes, pages playing sound are exempt (that is inherited from current mechanisms to align background timers to once a second).

On 11 Nov 2016 6:09 pm, "Darin Fisher" <da...@chromium.org> wrote:

This is really great, but are there any exceptions (e.g., for background pages playing sound)?

-Darin

On Fri, Nov 11, 2016 at 10:06 AM, Alexander Timin <alt...@chromium.org> wrote:

Contact emails

alt...@chromium.org

Design doc

Time-based renderer task throttling

Summary

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.

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

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: Expensive Background Timer Throttling

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

Yes.

Demo link

https://fiddle.jshell.net/vvL0e9x3/show/light

Interoperability and Compatibility Risk

Initial testing by enabling the feature locally by a small number of developers did not expose any problems. However, there exists a possibility of breakage of a major site, so we want to ship this feature via experiment-controlled rollout. This will allow us to quickly respond to issues (if any), by changing throttling aggressiveness or disabling throttling completely if necessary.

Firefox: No public signals

Edge: Positive

Safari: No public signals

OWP launch tracking bug

crbug.com/650594

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes.

--

Kentaro Hara, Tokyo, Japan

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

Hi Rick,

We pushed the config to beta a week ago and gathered feedback from web devs. 

Based on this feedback we will not ship this intervention in M56 and improve opt-outs from this intervention (i.e. we won't throttle when a page has an active websocket connection. We also will consider supporting a metatag for explicit opt-out).

I'm hoping to ship it in M57 and we will have a blog post and other outreach closer to shipping M57.

Hopefully this answers your question.

Alexander

[Rick Byers]

Thanks Alexander,

I just had a chat with Ojan about this and he explained that (unless we're missing something from the blink-dev thread) with the new 30s max-throttle pushed via finch this really shouldn't be breaking anyone anymore.  Effectively we were designing the first stage to be near zero-impact, and so developer outreach shouldn't be necessary at this stage.  That this is really just an implementation detail.

If it's true that we believe this isn't going to cause non-trivial breakage, then I'm OK with continuing with the plan to ship in M56 without a blog post (although it's still important that the bug tracker and chromestatus accurately reflect the shipping status).

That said, if you feel the concern we're hearing on blink-dev is legitimate and you'd rather do some more work (such as the websocket mitigation) and launch in 57 then that's fine by me too.  But we definitely shouldn't be afraid to improve the user experience here only because of a handful of web developers who are opposed in principle but aren't necessarily impacted negatively in practice.

It's good that we're being aggressive about improving the user experience, I'm mostly just concerned that we're being transparent and responsible about how we do it.

What do you think?

[Alexander Timin]

To be honest, I don't have a final opinion on rollout plan and whether we should ship in M56 (I'm somewhat scared about rolling out this intervention without an opt-out).

I'm in MTV next week for the BlinkOn and I was hoping to chat with Ojan and other stakeholders and finalize a plan.

Alexander

[Ojan Vafai]

I haven't heard anything that makes me think we should revert given that we changed it to limit to worst-case 30 seconds and that we believe the immediate user benefit to be large. If we're really worried, we should tweak the parameters to make them even more permissive. I want to get this code out there so we can see basic things like whether there's bugs we hadn't thought of, whether we see the impact in UMA that we expect, etc.

I found http://blog.strml.net/2017/01/chrome-56-now-aggressively-throttles.html to be very telling. Specifically, the comments were very positive about this change IMO. 

FeaturePolicy is slated to ship in M58. We should make sure to have an appropriate opt-out in M58. Then the question is just what throttling levels we do. First in M56/57, then later in M58 that has the opt out. Let's talk next week about what the opt-out should do, what the end-goal is (e.g. is the goal to fully suspend tabs), and what the incremental steps in that direction are.

It's my bad for not having sufficiently good public messaging here. We should state a clear public plan of the goal so that people understand where we're planning to push the ecosystem and on what timeline. For example, we can clearly state there that ServiceWorkers won't have the same throttling needs because they already get killed (i.e. you have to use PushNotifications).

It's a plan that will sadly have to evolve though as our understanding of the problem does. That's part of what makes this particularly hard. We have to ship to see what the problems are. So it's a bit chicken and egg.

Alexander

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

[Dru Knox]

+Taylor for his thoughts on interventions+outreach. @Taylor, is this something DevX should be tracking/helping with?

You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTu_Sy_rLDi1PhMiCa%2BP01EadMMrk9s5VyyfBKcmhmiMCg%40mail.gmail.com.

[Chris Harrelson]

Hi,

I'm concerned about the outpouring of concerned commentary on blink-dev. If that hasn't happened already, could someone reach out to each of those people and verify that that they are not negatively impacted by the current iteration of the intervention?

Thanks,

Chris

Alexander

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 "intervention-dev" group.

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

To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTu_Sy_rLDi1PhMiCa%2BP01EadMMrk9s5VyyfBKcmhmiMCg%40mail.gmail.com.

--

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

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

To post to this group, send email to interven...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAJcfO47pSSvn7oUdTUn8qKhVzF6x3-eriNsYRfd_9pKz%2BkFGtQ%40mail.gmail.com.

[Alexander Timin]

Hi Chris,

I'm closely monitoring all emails and reaching out to people. At the moment seems that adding an exception for frames with websockets solves all concerns. 

I will continue to monitor the situation and will give an update if this changes.

...

[Chris Harrelson]

Great, thank you. And sorry for the slow reply.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CALHg4n%3D6MAp-4%2BuyEb8ZGG5MiGsw514Hat_H37rE%3D8zU4BZHVg%40mail.gmail.com.