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 On Thu, Oct 5, 2017 at 5:36 PM, Gabor Krizsanits <gkrizsan...@mozilla.com> wrote: > 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 > > On Thu, Oct 5, 2017 at 5:27 PM, Andreas Farre <fa...@mozilla.com> 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 > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
