1494133 - Add new telemetry probe to know how many locahost suspended by e10s back pressure

Status: RESOLVED FIXED

(Core :: Networking: HTTP, enhancement, P3)

Description

[Junior [inactive]]

We have 4-5% resources are suspended by back pressure in nightly and 3% in beta. That's out of our expectation.

Start to investigate something.
If it's not big difference of loading time, we can live with it.

Comment 1

[Junior [inactive]]

I want to limit the size between 1MB-8MB for the telemetry.

Comment 2

[Junior [inactive]]

Attachment: Bug 1494133 - add telemetry to know the loading time with/without suspension by back pressure

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to Junior Hsu from comment #2)
> Created attachment 9011994 [details]
> Bug 1494133 - add telemetry to know the loading time with/without suspension
> by back pressure

This will not show much because the load time is so much dependent on the network.

We assume that that the back pressure most probably is turned on for loads from localhost. Let's split NETWORK_BACK_PRESSURE_SUSPENSION_RATE for localhost and non-localhost.This telemetry does not need to run on release, I would say.

Comment 4

[Honza Bambas (:mayhemer)]

(In reply to Junior Hsu from comment #0)
> We have 4-5% resources are suspended by back pressure in nightly and 3% in
> beta. That's out of our expectation.

I'm a bit curious why that is out of our expectation.  Any expectation we had were purely guessing.  If this is the rate then it may just prove that we actually did need the backpressure and that it now does its job.

With that line I'm not opposing to add this telemetry probe.

I agree with comment 3.

Comment 5

[Junior [inactive]]

Attachment: Bug 1494133 - know how many localhosts suspended by e10s back pressure

Comment 6

[Junior [inactive]]

Pinging for review in case the notification is accidentally dropped

Comment 7

[Junior [inactive]]

(In reply to Junior Hsu from comment #6)
> Pinging for review in case the notification is accidentally dropped

BTW, it's attachment 9012743 [details]
I cancel the review of the *original* one since the plan is changed per Comment 3

Comment 8

[Junior [inactive]]

Transferred the reviewer.

Comment 9

[Junior [inactive]]

Attachment: request.txt

datareview?

Comment 10

[Junior [inactive]]

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

Comment 11

[François Marier [:francois]]

Comment on attachment 9014057 [details]
request.txt

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes, in Histograms.json.

2) Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, telemetry setting.

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

Not permanent.

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, only 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?

No, telemetry alerts are enough.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8881fb305475
know how many localhosts suspended by e10s back pressure r=valentin

Comment 13

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/8881fb305475