1413839 - Add telemetry to probe how close we’re going to block main thread

Status: RESOLVED FIXED

(Core :: Networking: Cookies, enhancement, P2)

Description

[Junior [inactive]]

MOZ_SQLITE_COOKIES_BLOCK_MAIN_THREAD_MS shows we won't block the main thread with  >99.9% probability [1]. What we want to do is to measure how close we’re going to block main thread. And stop to record the non-blocking case in MOZ_SQLITE_COOKIES_BLOCK_MAIN_THREAD_MS (it would be covered by new probe)

[1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-10-31&keys=__none__!__none__!__none__&max_channel_version=nightly%252F58&measure=MOZ_SQLITE_COOKIES_BLOCK_MAIN_THREAD_MS&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-10-24&table=0&trim=1&use_submission_date=0

Comment 1

[Junior [inactive]]

Attachment: timeToBlockMainThread, v1

Comment 2

[Junior [inactive]]

Attachment: timeToBlockMainThread, v2

Sorry for spam a wrong file.

Comment 3

[u408661]

Comment on attachment 8928872 [details] [diff] [review]
timeToBlockMainThread, v2

Review of attachment 8928872 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.

::: netwerk/cookie/nsCookieService.cpp
@@ +2773,5 @@
> +    // We didn't block main thread, and here comes the first cookie request.
> +    // Collect how close we're going to block main thread.
> +    Telemetry::Accumulate(Telemetry::MOZ_SQLITE_COOKIES_TIME_TO_BLOCK_MAIN_THREAD_MS,
> +                          (TimeStamp::Now() - mEndInitDBConn).ToMilliseconds());
> +    mEndInitDBConn = TimeStamp();

Make a note here that this makes the timestamp null so we don't accumulate this telemetry probe multiple times.

::: toolkit/components/telemetry/Histograms.json
@@ +4452,5 @@
> +    "alert_emails": ["[e-mail]", "[e-mail]"],
> +    "bug_numbers": [1413839],
> +    "high": 10000,
> +    "n_buckets": 30,
> +    "description": "How close we will block main thread by startup cookie database read (ms), 0 for blocking case"

"How long (ms) after we finished reading the cookie db until the first cookie request came in (0 implies we blocked the main thread)"

Comment 4

[Junior [inactive]]

Attachment: timeToBlockMainThread, v3

Comment 5

[Junior [inactive]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dce9014976fb85ac184e9db5b289bc742553d970

Comment 6

[Junior [inactive]]

Comment on attachment 8929292 [details] [diff] [review]
timeToBlockMainThread, v3

1) What questions will you answer with this data?
how close we’re going to block main thread for cookie db startup reading.

2) Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?
If we figure we're very close to block main thread, we need to do something to avoid this.
No product and biz requirements.

3) What alternative methods did you consider to answer these questions? Why were they not sufficient?
We already have a telemetry to see how long we block the main thread. It's <0.1% to blocking.
Hence we'd like to know how close we're going to block. That's a more informative data.

4) Can current instrumentation answer these questions?
no

5) List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the found on the Mozilla wiki.

Only one probes here
MOZ_SQLITE_COOKIES_TIME_TO_BLOCK_MAIN_THREAD_MS
It's Category 1 “Technical data”
How long (ms) after we finished reading the cookie db until the first cookie request came in (0 implies we blocked the main thread)"

6) How long will this data be collected? Choose one of the following:
It's a cheap telemetry. We ping the server one time for every startup.

7) What populations will you measure?
central mainly, good to know in nightly, beta

8) Please provide a general description of how you will analyze this data.
Simply see the numbers like question 2.

9) Where do you intend to share the results of your analysis?
Only in bugzilla in Network:Cookies components

Comment 7

[François Marier [:francois]]

Comment on attachment 8929292 [details] [diff] [review]
timeToBlockMainThread, v3

Review of attachment 8929292 [details] [diff] [review]:
-----------------------------------------------------------------

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate? (see [here](https://github.com/mozilla/activity-stream/blob/master/docs/v2-system-addon/data_dictionary.md), [here](https://github.com/mozilla-mobile/focus/wiki/Install-and-event-tracking-with-the-Adjust-SDK), and [here](https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/index.html) for examples).  Refer to the appendix for "documentation" if more detail about documentation standards is needed.

Yes, in histograms.json

2) Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.

Yes, telemetry.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**

Yes, Junior and necko team.

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **

Category 1.

5) Is the data collection request for default-on or default-off?

default-on in pre-release channels.

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?

No.

7) Is the data collection covered by the existing Firefox privacy notice?

Yes.

8) Does there need to be a check-in in the future to determine whether to renew the data? (Yes/No) (If yes, set a todo reminder or file a bug if appropriate)**

No, it doesn't expire.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b3cea56174a
Add telemetry to probe how close we are going to block main thread. r=ngwh, data-r=francois

Comment 9

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/8b3cea56174a