Add new UMA to record the bytes wasted due to download resumption

Add new UMA to record the bytes wasted due to download resumption

When resuming a download, it is possible chrome discards some of the data received.
This CL adds a new UMA histogram to track how much data is wasted due to this.
To make things simple, we check if bytes received keep on increasing on each update.
If the data received drops, that means the data is wasted.
This logic is not 100% accurate, as the update is not called on every byte change.
However, it should work in most of the cases, and we are only interested in a rough number.
This CL also changes the UMA SharedPrefs.
So have to do some conversions from old sharedpref version.

BUG=679092
, whenever download updates, we check if the bytes received

Review-Url: https://codereview.chromium.org/2681033002
Cr-Commit-Position: refs/heads/master@{#450415}
Committed: https://chromium.googlesource.com/chromium/src/+/541b4d75ca2d4994ac15dac596aa10be9ff180c1

[qinmin, 2017-02-08 01:02:45]

qinmin@chromium.org changed reviewers:
+ isherman@chromium.org, shaktisahu@chromium.org

[qinmin, 2017-02-08 01:02:46]

+isherman for histogram
+shaktisahu for download changes, feel free to ping me if you have questions
related to download

[Ilya Sherman, 2017-02-08 02:11:20]

Metrics LGTM % nits:

https://codereview.chromium.org/2681033002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
(right):

https://codereview.chromium.org/2681033002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java:95:
private static final int GB_IN_KILO_BYTES = 1000 * 1000;
Are you sure that you want 1000 * 1000 and not 1024 * 1024?

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:27977: +<histogram
name="MobileDownload.BytesWasted" units="KB">
nit: Please add the attribute base="true"

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:113884: +  <suffix
name="ChromeNetworkStack.Failure"/>
nit: Please add a label like "Recorded upon download failure."

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:113886: +  <suffix
name="ChromeNetworkStack.Cancel"/>
nit: Why not include "ChromeNetworkStack" in the histogram base histogram name?

[qinmin, 2017-02-09 01:05:11]

https://codereview.chromium.org/2681033002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
(right):

https://codereview.chromium.org/2681033002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java:95:
private static final int GB_IN_KILO_BYTES = 1000 * 1000;
On 2017/02/08 02:11:19, Ilya Sherman (Away til Feb 10) wrote:
> Are you sure that you want 1000 * 1000 and not 1024 * 1024?

Switched to use 1024 * 1024. However, we don't really need exact numbers here,
so both are fine. In RecordHistogram.java, e.g, we use 1000 instead of 1024 in
most places

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:27977: +<histogram
name="MobileDownload.BytesWasted" units="KB">
On 2017/02/08 02:11:19, Ilya Sherman (Away til Feb 10) wrote:
> nit: Please add the attribute base="true"

Done.

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:113884: +  <suffix
name="ChromeNetworkStack.Failure"/>
On 2017/02/08 02:11:19, Ilya Sherman (Away til Feb 10) wrote:
> nit: Please add a label like "Recorded upon download failure."

Done.

https://codereview.chromium.org/2681033002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:113886: +  <suffix
name="ChromeNetworkStack.Cancel"/>
On 2017/02/08 02:11:19, Ilya Sherman (Away til Feb 10) wrote:
> nit: Why not include "ChromeNetworkStack" in the histogram base histogram
name?

Done.

[qinmin, 2017-02-14 17:33:54]

The CQ bit was checked by qinmin@chromium.org

[qinmin, 2017-02-14 17:33:55]

The patchset sent to the CQ was uploaded after l-g-t-m from
isherman@chromium.org
Link to the patchset: https://codereview.chromium.org/2681033002/#ps20001
(title: "addressing comments")

[commit-bot: I haz the power, 2017-02-14 17:34:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-14 18:38:27]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1487093634701200,
"parent_rev": "1fc45bea3a9806a25cf9b0b38466f62c35f785d6", "commit_rev":
"541b4d75ca2d4994ac15dac596aa10be9ff180c1"}

[commit-bot: I haz the power, 2017-02-14 18:39:02]

Description was changed from

==========
Add new UMA to record the bytes wasted due to download resumption

When resuming a download, it is possible chrome discards some of the data
received.
This CL adds a new UMA histogram to track how much data is wasted due to this.
To make things simple, we check if bytes received keep on increasing on each
update.
If the data received drops, that means the data is wasted.
This logic is not 100% accurate, as the update is not called on every byte
change.
However, it should work in most of the cases, and we are only interested in a
rough number.
This CL also changes the UMA SharedPrefs.
So have to do some conversions from old sharedpref version.

BUG=679092

, whenever download updates, we check if the bytes received
==========

to

==========
Add new UMA to record the bytes wasted due to download resumption

When resuming a download, it is possible chrome discards some of the data
received.
This CL adds a new UMA histogram to track how much data is wasted due to this.
To make things simple, we check if bytes received keep on increasing on each
update.
If the data received drops, that means the data is wasted.
This logic is not 100% accurate, as the update is not called on every byte
change.
However, it should work in most of the cases, and we are only interested in a
rough number.
This CL also changes the UMA SharedPrefs.
So have to do some conversions from old sharedpref version.

BUG=679092

, whenever download updates, we check if the bytes received

Review-Url: https://codereview.chromium.org/2681033002
Cr-Commit-Position: refs/heads/master@{#450415}
Committed:
https://chromium.googlesource.com/chromium/src/+/541b4d75ca2d4994ac15dac596aa...
==========

[commit-bot: I haz the power, 2017-02-14 18:39:05]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/541b4d75ca2d4994ac15dac596aa...