Intent to ship: Throttling timeouts in background using execution budget.

[Andreas Farre]

Hi all!

After Bug 1377766 lands, we will increase the amount timeouts
executing in background tabs are throttled, based on an execution
budget. This budget is continuously regenerating, and is decreased
when timeouts execute. If the budget becomes negative, timeouts will
not be allowed to run until the budget is positive again. This
punishes pages that behave poorly while not being in the foreground.

This feature has been developed behind
"dom.timeout.enable_budget_timer_throttling". Other relevant prefs
are:

* dom.timeout.background_budget_regeneration_rate
The rate of budget regeneration; the time in milliseconds that it
takes to regenerate 1 millisecond

* dom.timeout.background_throttling_max_budget
The maximum budget. Budget is clamped to this.

* dom.timeout.budget_throttling_max_delay
Effectively the minimum budget. The maximum delay of a throttled timeout

* dom.timeout.foreground_budget_regeneration_rate
The same as the background variant, but for foreground tabs. Only
applicable for testing.

* dom.timeout.foreground_throttling_max_budget
The same as the background variant, but for foreground tabs. Only
applicable for testing.

* dom.timeout.throttling_delay
The amount of time we require to pass after a page has completely
loaded until we start throttling.

The default values of these prefs are:

dom.timeout.background_budget_regeneration_rate: 100

dom.timeout.background_throttling_max_budget: 50

dom.timeout.budget_throttling_max_delay: 15000

dom.timeout.foreground_budget_regeneration_rate: 1

dom.timeout.foreground_throttling_max_budget: -1

dom.timeout.throttling_delay: 30000

This is read as: budget regenerates 10 ms per second and will never
grow beyond 50 ms. If the execution budget is negative a timeout will
not run until it becomes positive, which happens at the said rate, but
it will also not be delayed more than 15 seconds. Throttling for
foreground is effectively turned off. Throttling doesn't commence
until after 30 seconds.

Google has a similar feature[1] for timer throttling.

Turning on this feature is tracked in Bug 1377766 [2]

It is inherently difficult to test this feature without false
negatives due to the timing dependency of the feature. Bug 1378402
tracks adding tests for testing throttling, but they suffer from being
a bit too intermittent still. At least for debug builds.

My hope by getting this in early in the release cycle is to be able to
actively evaluate the feature, so I hope that you take the time to
report those bugs! :)

My hope is that this will land on Monday October 9th if there are no objections.

Cheers, Andreas

[1] https://developers.google.com/web/updates/2017/03/background_tabs#budget-based_background_timer_throttling
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1377766
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1378402

[Gabor Krizsanits]

Thanks a lot for working on this, it sounds awesome! Can I ask if there are
any related telemetry probes that will be used later on to evaluate the
results and maybe tune these constants? Do you plan to expose any of these
parameters to web extensions?

Gabor

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Andreas Farre]

Yes, there are related telemetry probes, but I've recently convinced
myself that they won't be able to clearly detect budget throttling.
The probe is TIMEOUT_EXECUTION_BG_MS, and the reason for it not
working is that it accumulates execution over one second, which just
happens to be the time of the already existing background throttling
of timeouts. This is an unfortunate mistake (by myself), and could
possibly be alleviated by adding another probe
TIMEOUT_EXECUTION_BG_15_MS, or changing TIMEOUT_EXECUTION_BG_MS to
accumulate over 15 seconds. Adding another probe is a bit unfortunate,
since that means that basically the entire functionality for the first
probe needs to be duplicated, changing the accumulation time is also
unfortunate, since a shield study looking at a sibling probe is
currently underway. It might be possible to do a transformation of
TIMEOUT_EXECUTION_BG_MS to a value that tells us something, since the
number of data points should effectively decrease, even though the
value the probe doesn't change. Also, any change to the probes would
either need to delay landing or be upstreamed, both of which I'd like
to avoid :)

It's also possible that CONTENT_JS_BACKGROUND_TICK_DELAY_TOTAL_MS,
CONTENT_JS_KNOWN_TICK_DELAY_JS could show us something, since they
track how much vsyncs gets delayed due to events that run in the
background, and that's how timeouts from the background also run.

Currently there is no plan to expose these parameters through web
extensions, but I can see the point of it.

Cheers,
Andreas

[Andreas Farre]

Hi!

I forgot to mention this issue, thank you for bringing it up.
Background throttling is disabled whenever something that is
considered real time, like audio, or could potentially time out, like
web sockets, is present on he page, including iframes.

To both prove to myself that these mechanisms work, as well as the
entire feature, I've created a visualiser:

https://farre.github.io/web-tools/load/

The UI is a bit messy to say the least, but if you don't need to
configure anything you can just hit 'Run test' and make sure to allow
the pop up. After that a uniform load of 50% will be generated, spread
out over 10 timeouts during one second. This will happen in the tab
with the UI, so don't switch back to that from the pop-up, because
then throttling will be canceled. The pop-up runs this load for each
of the unthrottlers (stuff that makes budget throttling impossible),
and half-way during that period (typically 40 seconds) it adds the
unthrottler. I've added some screenshots! The first shows how it looks
like with no unthrottler and with a RTCPeerConnection present. Here we
see how the timeout starts out at the once per second background
throttling, then goes down to the circa 1% background throttling due
to budget constraints, and then back again to the 5% level. The second
screenshot shows what happens when audio starts in the background, and
here we see that we start at 5%, go down to 1%, but when audio starts
playing we get the load that we requested completely unthrottled!

I've tried it out with Edge and Chrome as well, and with it you can
see how throttling works there. On caveat though, both Chrome and Edge
only throttle daisy chained timeouts, and the default settings for the
test is to fire off 10 timeouts, that are spread out without overlap.
To get it to work in Chrome and Edge, change 'Slices#' to 1 and
'Period' to 100, which will still get you a 50% load, but with daisy
chained timeouts, one every 100 ms.

Remember to flip the pref if you want to try the visualiser out! It's
dom.timeout.enable_budget_timer_throttling, and I've been running with
it on for weeks without problems :)

Cheers,
Andreas



On Thu, Oct 5, 2017 at 5:39 PM, Soledad Penadés <so...@mozilla.com> wrote:
> Hello!
>
> This sounds like a cool feature, thanks for that! However, as you said, it's
> easier to get this wrong. I wonder if you have tested this with Web Audio
> scenarios in mind. We had a similar issue a while ago where web audio
> scheduled with setTimeouts (a common practice) would time out when eager
> optimisations were in place:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1375119
>
> sole

> --
> http://soledadpenades.com
>