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 <s...@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 > > > > On 05/10/2017 16:27, Andreas Farre wrote: >> >> 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 >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > > > -- > http://soledadpenades.com > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
