New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 793388 link

Starred by 1 user
Status: Assigned
Owner:
█ nyquist@chromium.org
Traveling - Back 2/6
Cc:
dtrainor@chromium.org
ios-bugs@chromium.org
█ nyquist@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac
Pri: 2
Type: Feature



Sign in to add a comment

Add metrics for Feature Engagement Tracker initialization latency.

Project Member Reported by gch...@chromium.org, Dec 8 2017 
Since the latency of the Feature Engagement Tracker initialization can be variable, we should add metrics to record this latency.

Comment 1 by nyquist@chromium.org, Dec 8 2017

Cc: dtrainor@chromium.org
Components: Internals>FeatureEngagement
Labels: -Type-Bug OS-Chrome OS-Linux OS-Mac OS-Windows Type-Feature
We probably want to add at least the following:

- Time from we start init of the Tracker itself, until it's initialized.
  - This spawns the other two DB initializations.
- Time from we start init of EventModel until it's initialized.
- Time from we start init of AvailabilityModel until it's initialized.

We should look at other typical DB loads to see if they use different stats for when load fails or not.

dtrainor: Do you think we should split load-times based on whether we succeeded or not?

Comment 2 by dtrainor@chromium.org, Dec 8 2017 

Yeah I think it'd be interesting to see that data and wouldn't take much extra work.

Comment 3 by nyquist@chromium.org, Dec 8 2017 

We probably want to split the histograms for init time into separate ones for:
- Success
- Success, but did recreate (not available yet for feature engagement)
- Failed after recreate
- ...

Or something along those lines.

Comment 4 by nyquist@chromium.org, Jan 25 2018

Labels: -Pri-3 M-66 Pri-2
►

Sign in to add a comment