tools/metrics/actions/actions.xml - Issue 703453004: Plugin Power Saver: Add some UMAs to test plugins in wild.

Unified Diff: tools/metrics/actions/actions.xml

Issue 703453004: Plugin Power Saver: Add some UMAs to test plugins in wild. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: add back plugininstancecreated uma Created 6 years, 1 month ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

« content/renderer/pepper/plugin_power_saver_helper.cc ('K') | « content/renderer/pepper/plugin_power_saver_helper.cc ('k') | tools/metrics/histograms/histograms.xml » ('j') | tools/metrics/histograms/histograms.xml » ('J')
Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

Index: tools/metrics/actions/actions.xml

diff --git a/tools/metrics/actions/actions.xml b/tools/metrics/actions/actions.xml

index e17f646d7352d0aac9a229ed7af03cdf6afcaada..e43f12780db9e727822cf199c0c2f9bdcf7c3c2f 100644

--- a/tools/metrics/actions/actions.xml

+++ b/tools/metrics/actions/actions.xml

@@ -2659,7 +2659,24 @@ should be able to be added at any place in this file.

<owner>thestig@chromium.org</owner>

- <description>Count of frame loads that also load PPAPI Flash.</description>

+ <description>Count of Flash plugin instances.</description>

+</action>

+<action name="Flash.PluginInstanceUnthrottledByClick">

+ <owner>thestig@chromium.org</owner>

+ <description>

+ Count of peripheral Flash plugin instances later marked essential by a user

+ click.

+ </description>

+</action>

+<action name="Flash.PluginInstanceUnthrottledByWhitelist">

+ <owner>thestig@chromium.org</owner>

+ <description>

+ Count of peripheral Flash plugin instances later marked essential by a

+ retroactive update of the whitelist. These retroactive updates are usually

+ happen at the speed of IPC and look instantaneous.

+ </description>

</action>

Ilya Sherman 2014/11/05 22:36:19 Are you sure you want to log these as actions rath

tommycli 2014/11/06 00:36:05 I thought these might be 'actions' since not every

Ilya Sherman 2014/11/06 03:30:30 The idea of building a histogram would be to have

The idea of building a histogram would be to have a histogram that has one bucket that records e.g. the number of plugin instances that are created, and to have two other buckets for recording how many times such plugins were unthrottled, either by click or by whitelist. The nice thing about histograms is that they have context built in to them -- you don't have to guess at which other actions are meant to be used as baselines. We do log every single user action and every single histogram (well, for users who are opted in to sharing metrics, of course). The main advantages of user actions are that (a) they have timestamps associated with them, and (b) they allow easy comparisons to arbitrary other actions. As a result, actions are typically used to measure user interactions with Chrome, and especially to gauge feature usage at a high level. The main advantages of histograms are that (a) they are more efficient, (b) they have a built-in baseline, which often makes data analysis much easier, and (c) they are much better supported on the dashboard side. Hence, histograms are typically used when adding metrics that are designed to answer specific questions like "How often are plugins getting unthrottled?", where you expect that comparing events recorded in your histogram with events like "How many times did a user enable Autofill?" is not a useful comparison.

tommycli 2014/11/06 21:16:13 Okay that was very helpful. I made it a histogram

On 2014/11/06 03:30:30, Ilya Sherman wrote: > On 2014/11/06 00:36:05, tommycli wrote: > > On 2014/11/05 22:36:19, Ilya Sherman wrote: > > > Are you sure you want to log these as actions rather than as an enumerated > > > histogram? What advantage do you see from logging these as actions? (It > > might > > > be the right choice, but I'd like to understand the context so that I can > > > provide better guidance.) > > > > I thought these might be 'actions' since not every plugin is unthrottled. We > > expect that many plugins that get throttled are never unthrottled. > > > > Do we log every single user action / histogram, or do we take a sparse > sampling > > from our users? > > The idea of building a histogram would be to have a histogram that has one > bucket that records e.g. the number of plugin instances that are created, and to > have two other buckets for recording how many times such plugins were > unthrottled, either by click or by whitelist. The nice thing about histograms > is that they have context built in to them -- you don't have to guess at which > other actions are meant to be used as baselines. > > We do log every single user action and every single histogram (well, for users > who are opted in to sharing metrics, of course). The main advantages of user > actions are that (a) they have timestamps associated with them, and (b) they > allow easy comparisons to arbitrary other actions. As a result, actions are > typically used to measure user interactions with Chrome, and especially to gauge > feature usage at a high level. > > The main advantages of histograms are that (a) they are more efficient, (b) they > have a built-in baseline, which often makes data analysis much easier, and (c) > they are much better supported on the dashboard side. Hence, histograms are > typically used when adding metrics that are designed to answer specific > questions like "How often are plugins getting unthrottled?", where you expect > that comparing events recorded in your histogram with events like "How many > times did a user enable Autofill?" is not a useful comparison.

Okay that was very helpful. I made it a histogram. I added a third possibility of 'Never' to denote plugins that are throttled but never unthrottled. With the three options combined, we should be able to get a clear picture of what happens to ALL plugins after they get throttled.