bluetooth: Add histograms and logging for getPrimaryService()

bluetooth: Add histograms and logging for getPrimaryService()

Three new histograms:
 - GetPrimaryService.Services: Record UUID of the service passed
 - GetprimaryService.Time: Record time it took to discover all of the device's services
 - GetPrimaryService.Outcome: Record outcome of the getPrimaryService() call

Log:
 - If a device is no longer present
 - If no services match the UUID passed

BUG=499636
Committed: https://crrev.com/3b01950e75972628728065c2d88569a53648f30d
Cr-Commit-Position: refs/heads/master@{#343147}

[ortuno, 2015-08-12 16:41:33]

Patchset #1 (id:1) has been deleted

[ortuno, 2015-08-12 16:41:37]

Patchset #1 (id:20001) has been deleted

[ortuno, 2015-08-12 16:41:56]

ortuno@chromium.org changed reviewers:
+ jyasskin@chromium.org

[ortuno, 2015-08-12 16:41:56]

@jyasskin: PTAL

[Jeffrey Yasskin, 2015-08-12 17:00:04]

https://codereview.chromium.org/1271043002/diff/40001/content/browser/bluetoo...
File content/browser/bluetooth/bluetooth_dispatcher_host.cc (right):

https://codereview.chromium.org/1271043002/diff/40001/content/browser/bluetoo...
content/browser/bluetooth/bluetooth_dispatcher_host.cc:136:
UMA_HISTOGRAM_MEDIUM_TIMES("Bluetooth.Web.GetPrimaryService.Time", duration);
This is more the ServiceDiscoveryTime or the GetPrimaryService.DiscoveryTime
than the GetPrimaryService.Time, since it doesn't include any of the other work
in GetPrimaryService.

We should probably also avoid recording times when services are already
discovered.

https://codereview.chromium.org/1271043002/diff/40001/content/browser/bluetoo...
content/browser/bluetooth/bluetooth_dispatcher_host.cc:516: device_instance_id,
service_uuid, start_time),
Right now, this isn't a useful time to record since it'll always be close to
current_delay_time_. I'm not sure of this, but maybe we should wait to record
the timing information until we're actually getting notified when discovery
finishes. That'll also make sure we measure the relevant things at that point.

[ortuno, 2015-08-12 18:18:05]

https://codereview.chromium.org/1271043002/diff/40001/content/browser/bluetoo...
File content/browser/bluetooth/bluetooth_dispatcher_host.cc (right):

https://codereview.chromium.org/1271043002/diff/40001/content/browser/bluetoo...
content/browser/bluetooth/bluetooth_dispatcher_host.cc:136:
UMA_HISTOGRAM_MEDIUM_TIMES("Bluetooth.Web.GetPrimaryService.Time", duration);
On 2015/08/12 at 17:00:04, Jeffrey Yasskin wrote:
> This is more the ServiceDiscoveryTime or the GetPrimaryService.DiscoveryTime
than the GetPrimaryService.Time, since it doesn't include any of the other work
in GetPrimaryService.
> 
> We should probably also avoid recording times when services are already
discovered.

Histogram removed.

https://codereview.chromium.org/1271043002/diff/40001/content/browser/bluetoo...
content/browser/bluetooth/bluetooth_dispatcher_host.cc:516: device_instance_id,
service_uuid, start_time),
On 2015/08/12 at 17:00:04, Jeffrey Yasskin wrote:
> Right now, this isn't a useful time to record since it'll always be close to
current_delay_time_. I'm not sure of this, but maybe we should wait to record
the timing information until we're actually getting notified when discovery
finishes. That'll also make sure we measure the relevant things at that point.

Histogram removed.

[Jeffrey Yasskin, 2015-08-12 18:23:11]

lgtm

https://codereview.chromium.org/1271043002/diff/60001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1271043002/diff/60001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:2814: +    Records what GATT Services
are used when connected. This will help us know
Mention this is a hash, like for RequestDevice.

[ortuno, 2015-08-12 18:27:24]

https://codereview.chromium.org/1271043002/diff/60001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1271043002/diff/60001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:2814: +    Records what GATT Services
are used when connected. This will help us know
On 2015/08/12 at 18:23:11, Jeffrey Yasskin wrote:
> Mention this is a hash, like for RequestDevice.

Done.

[ortuno, 2015-08-12 18:27:38]

ortuno@chromium.org changed reviewers:
+ asvitkine@chromium.org

[ortuno, 2015-08-12 18:27:39]

@asvitkine: PTAL

[Alexei Svitkine (slow), 2015-08-12 18:28:45]

lgtm

[ortuno, 2015-08-12 18:32:27]

ortuno@chromium.org changed reviewers:
+ scheib@chromium.org

[ortuno, 2015-08-12 18:32:28]

@scheib: PTAL

[scheib, 2015-08-12 21:10:51]

LGTM

[ortuno, 2015-08-12 22:53:47]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-08-12 22:54:25]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1271043002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1271043002/100001

[commit-bot: I haz the power, 2015-08-13 00:12:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-08-13 00:12:21]

Dry run: This issue passed the CQ dry run.

[ortuno, 2015-08-13 01:43:01]

The CQ bit was checked by ortuno@chromium.org

[ortuno, 2015-08-13 01:43:01]

The patchset sent to the CQ was uploaded after l-g-t-m from
jyasskin@chromium.org, asvitkine@chromium.org, scheib@chromium.org
Link to the patchset: https://codereview.chromium.org/1271043002/#ps100001
(title: "Merge")

[commit-bot: I haz the power, 2015-08-13 01:43:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1271043002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1271043002/100001

[commit-bot: I haz the power, 2015-08-13 01:48:27]

Committed patchset #4 (id:100001)

[commit-bot: I haz the power, 2015-08-13 01:49:04]

Patchset 4 (id:??) landed as
https://crrev.com/3b01950e75972628728065c2d88569a53648f30d
Cr-Commit-Position: refs/heads/master@{#343147}