Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2524533002:
Added UMA for usage of BudgetAPI calls. (Closed)
DescriptionAdded UMA for usage of BudgetAPI calls.
Although there are metrics for the budget and SES at the time that budget
is consumed, there isn't currently any tracking for which events in the
budget system come via the Budget API interface.
This adds two new metrics, to track queries and reserve requests. It also
adds some basic testing to ensure the metrics are being recorded.
BUG=617971
Committed: https://crrev.com/2b5939812baa7c97c1d908b10150d7ad7109dc31
Cr-Commit-Position: refs/heads/master@{#436249}
Patch Set 1 #
Total comments: 17
Patch Set 2 : Renamed the UMA, various code review comments integrated. #Patch Set 3 : Reverting file that slipped in #
Total comments: 2
Patch Set 4 : Reverting file that slipped in #Patch Set 5 : Added more information about interpreting results of budget query uma. #
Total comments: 10
Patch Set 6 : Code review comments #
Total comments: 2
Patch Set 7 : Reanmed BudgetAPI UMA to Blinklink.BudgetAPI and updated budget_at assignment. #Patch Set 8 : Rebase and switch to using STL types to match mojo changes. #
Messages
Total messages: 31 (13 generated)
harkness@chromium.org changed reviewers: + peter@chromium.org
https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager_unittest.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager_unittest.cc:160: EXPECT_EQ(25, num_samples); This is a fairly low bar to validate the UMA recording. However, I found in testing that the buckets weren't guaranteed to be equally distributed over the [0,100] range, so this was the only metric I could really guarantee would be correct.
https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.cc:137: budget[0]->budget_at); What is the added value of recording the immediate available budget here? I.e. how do you plan to use it? I would personally just make this a UMA_HISTOGRAM_BOOLEAN() histogram as well, where the boolean is the condition on line 133. https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.h (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.h:67: // details. micro nit: I don't think these comments (dito re: the following two methods) add any value at all. Up to you. https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager_unittest.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager_unittest.cc:158: for (const base::Bucket bucket : buckets) nit: const& (if we still need this) https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:49824: +<histogram name="PushMessaging.BudgetAPIQuery"> Why is this in the PushMessaging namespace? It's a different API https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:49824: +<histogram name="PushMessaging.BudgetAPIQuery"> needs an @units attribute (<histogram name=".." units="calls">?) https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:49834: +<histogram name="PushMessaging.BudgetAPIReserve"> dito on both counts (no pun intended)
https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.cc:137: budget[0]->budget_at); On 2016/11/28 10:59:00, Peter Beverloo wrote: > What is the added value of recording the immediate available budget here? I.e. > how do you plan to use it? > > I would personally just make this a UMA_HISTOGRAM_BOOLEAN() histogram as well, > where the boolean is the condition on line 133. I'd like to have an idea of whether the people who are using the API are using up their budget, so they're constantly checking their budget and finding that they're running out, vs people checking budget and having plenty. https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.h (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.h:67: // details. On 2016/11/28 10:59:00, Peter Beverloo wrote: > micro nit: I don't think these comments (dito re: the following two methods) add > any value at all. Up to you. I agree in this case. I've removed this one and the other two. https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager_unittest.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager_unittest.cc:158: for (const base::Bucket bucket : buckets) On 2016/11/28 10:59:00, Peter Beverloo wrote: > nit: const& (if we still need this) Done. https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:49824: +<histogram name="PushMessaging.BudgetAPIQuery"> On 2016/11/28 10:59:01, Peter Beverloo wrote: > needs an @units attribute (<histogram name=".." units="calls">?) Since I'm leaving it as recording budget, I changed the units to budget, which is consistent with some of the other measurement metrics. https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:49824: +<histogram name="PushMessaging.BudgetAPIQuery"> On 2016/11/28 10:59:01, Peter Beverloo wrote: > Why is this in the PushMessaging namespace? It's a different API As discussed in chat, I had originally chosen the PushMessaging namespace to be consistent with the other metrics, but I don't feel strongly about it, so I moved it to the BudgetAPI namespace. https://codereview.chromium.org/2524533002/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:49834: +<histogram name="PushMessaging.BudgetAPIReserve"> On 2016/11/28 10:59:01, Peter Beverloo wrote: > dito on both counts (no pun intended) Fixed the namespace, instead of units, I made the enum=BooleanSuccess" explicit.
https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.cc:137: budget[0]->budget_at); On 2016/11/28 13:58:04, harkness wrote: > On 2016/11/28 10:59:00, Peter Beverloo wrote: > > What is the added value of recording the immediate available budget here? I.e. > > how do you plan to use it? > > > > I would personally just make this a UMA_HISTOGRAM_BOOLEAN() histogram as well, > > where the boolean is the condition on line 133. > > I'd like to have an idea of whether the people who are using the API are using > up their budget, so they're constantly checking their budget and finding that > they're running out, vs people checking budget and having plenty. But since UMA gives us aggregated data, we have no way to check the chronology of the calls, nor cross-reference them with the origins for which they're called. That effectively gives us a boolean [0, >0], right? What insight does the granularity of having 50 buckets give us? https://codereview.chromium.org/2524533002/diff/40001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager_browsertest.cc (right): https://codereview.chromium.org/2524533002/diff/40001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager_browsertest.cc:118: ASSERT_TRUE(success()); why?
https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.cc:137: budget[0]->budget_at); On 2016/11/28 14:14:06, Peter Beverloo wrote: > On 2016/11/28 13:58:04, harkness wrote: > > On 2016/11/28 10:59:00, Peter Beverloo wrote: > > > What is the added value of recording the immediate available budget here? > I.e. > > > how do you plan to use it? > > > > > > I would personally just make this a UMA_HISTOGRAM_BOOLEAN() histogram as > well, > > > where the boolean is the condition on line 133. > > > > I'd like to have an idea of whether the people who are using the API are using > > up their budget, so they're constantly checking their budget and finding that > > they're running out, vs people checking budget and having plenty. > > But since UMA gives us aggregated data, we have no way to check the chronology > of the calls, nor cross-reference them with the origins for which they're > called. That effectively gives us a boolean [0, >0], right? What insight does > the granularity of having 50 buckets give us? My gut feel for the API is that it will be used by two types of consumers. One is the consumer who is very aggressive about using up their budget and will be constantly bouncing off 0 budget. The other is the user who only very rarely either checks budget or uses budget. So what I expect to see is a distribution of budget in this histogram that corresponds closely to the SES score of service workers who query budget. Then, I expect to see a big spike of usage in the 0-10 range, which I would guess will come from 1% of origins that uses the feature a lot. Unfortunately, you're right that if the histogram doesn't match what I expect, I'm not sure what conclusions we'll be able to draw from it. If you feel that's enough reason to restrict it to just the count, I can do that, but it didn't seem like there was a significant harm to having the extra info. https://codereview.chromium.org/2524533002/diff/40001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager_browsertest.cc (right): https://codereview.chromium.org/2524533002/diff/40001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager_browsertest.cc:118: ASSERT_TRUE(success()); On 2016/11/28 14:14:06, Peter Beverloo wrote: > why? I was doing testing on another CL and somehow two files leaked over. Removed now.
lgtm % comment https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.cc:137: budget[0]->budget_at); On 2016/11/28 16:09:09, harkness wrote: > On 2016/11/28 14:14:06, Peter Beverloo wrote: > > On 2016/11/28 13:58:04, harkness wrote: > > > On 2016/11/28 10:59:00, Peter Beverloo wrote: > > > > What is the added value of recording the immediate available budget here? > > I.e. > > > > how do you plan to use it? > > > > > > > > I would personally just make this a UMA_HISTOGRAM_BOOLEAN() histogram as > > well, > > > > where the boolean is the condition on line 133. > > > > > > I'd like to have an idea of whether the people who are using the API are > using > > > up their budget, so they're constantly checking their budget and finding > that > > > they're running out, vs people checking budget and having plenty. > > > > But since UMA gives us aggregated data, we have no way to check the chronology > > of the calls, nor cross-reference them with the origins for which they're > > called. That effectively gives us a boolean [0, >0], right? What insight does > > the granularity of having 50 buckets give us? > > My gut feel for the API is that it will be used by two types of consumers. One > is the consumer who is very aggressive about using up their budget and will be > constantly bouncing off 0 budget. The other is the user who only very rarely > either checks budget or uses budget. > > So what I expect to see is a distribution of budget in this histogram that > corresponds closely to the SES score of service workers who query budget. Then, > I expect to see a big spike of usage in the 0-10 range, which I would guess will > come from 1% of origins that uses the feature a lot. > > Unfortunately, you're right that if the histogram doesn't match what I expect, > I'm not sure what conclusions we'll be able to draw from it. If you feel that's > enough reason to restrict it to just the count, I can do that, but it didn't > seem like there was a significant harm to having the extra info. We have three variables for values in this histogram: 1) The amount of engagement a user has with a website. The highest engaged site for a particular user definitely doesn't have to be a 100. 2) Whether that particular website checks their budget. 3) Whether that particular website *uses* their budget. This histogram only knows (2). We cannot associate any of this with a particular user, their engagement and/or current budget, or origin. As such, I can't really come up with any valid conclusion we can make based on the data. Now, you're right that the cost of having a histogram is reasonably low. It is a situation of death by a thousand needles though, so we should have reasonable confidence that a histogram is going to get us good data. If I've made a logic error somewhere and you feel we can get good data, let's do it, but please clarify what it is that we'll get in histograms.xml.
https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/1/chrome/browser/budget_servi... chrome/browser/budget_service/budget_manager.cc:137: budget[0]->budget_at); On 2016/11/28 18:22:04, Peter Beverloo wrote: > On 2016/11/28 16:09:09, harkness wrote: > > On 2016/11/28 14:14:06, Peter Beverloo wrote: > > > On 2016/11/28 13:58:04, harkness wrote: > > > > On 2016/11/28 10:59:00, Peter Beverloo wrote: > > > > > What is the added value of recording the immediate available budget > here? > > > I.e. > > > > > how do you plan to use it? > > > > > > > > > > I would personally just make this a UMA_HISTOGRAM_BOOLEAN() histogram as > > > well, > > > > > where the boolean is the condition on line 133. > > > > > > > > I'd like to have an idea of whether the people who are using the API are > > using > > > > up their budget, so they're constantly checking their budget and finding > > that > > > > they're running out, vs people checking budget and having plenty. > > > > > > But since UMA gives us aggregated data, we have no way to check the > chronology > > > of the calls, nor cross-reference them with the origins for which they're > > > called. That effectively gives us a boolean [0, >0], right? What insight > does > > > the granularity of having 50 buckets give us? > > > > My gut feel for the API is that it will be used by two types of consumers. One > > is the consumer who is very aggressive about using up their budget and will be > > constantly bouncing off 0 budget. The other is the user who only very rarely > > either checks budget or uses budget. > > > > So what I expect to see is a distribution of budget in this histogram that > > corresponds closely to the SES score of service workers who query budget. > Then, > > I expect to see a big spike of usage in the 0-10 range, which I would guess > will > > come from 1% of origins that uses the feature a lot. > > > > Unfortunately, you're right that if the histogram doesn't match what I expect, > > I'm not sure what conclusions we'll be able to draw from it. If you feel > that's > > enough reason to restrict it to just the count, I can do that, but it didn't > > seem like there was a significant harm to having the extra info. > > We have three variables for values in this histogram: > > 1) The amount of engagement a user has with a website. The highest engaged > site for a particular user definitely doesn't have to be a 100. > 2) Whether that particular website checks their budget. > 3) Whether that particular website *uses* their budget. > > This histogram only knows (2). We cannot associate any of this with a particular > user, their engagement and/or current budget, or origin. As such, I can't really > come up with any valid conclusion we can make based on the data. > > Now, you're right that the cost of having a histogram is reasonably low. It is a > situation of death by a thousand needles though, so we should have reasonable > confidence that a histogram is going to get us good data. > > If I've made a logic error somewhere and you feel we can get good data, let's do > it, but please clarify what it is that we'll get in histograms.xml. Discussed in person, summarizing here. The budget in this histogram is of limited use by itself, but might be useful in combination with other histograms. It might not, but I would rather have the data and not use it than need it and not have it. Peter was also concerned that the data might be misinterpreted, so I've added more to the comment in histograms.xml to clarify the fuzziness of the metric. To be clear, we agree completely on having the histogram, because the count of queries is very useful, it's just whether the count is a raw count or a histogram of budget that we disagreed on.
harkness@chromium.org changed reviewers: + asvitkine@chromium.org
asvitkine: Please review code in tools/metrics/histograms/histograms.xml
https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager.cc:136: UMA_HISTOGRAM_COUNTS_100("BudgetAPI.QueryBudget", budget[0]->budget_at); Please refactor the code so the macro is only emitted once. Since each macro expands to a bunch of code. https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager_unittest.cc (right): https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager_unittest.cc:106: base::HistogramTester* GetHistogramTester() { return &histogram_tester_; } Nit: histogram_tester() https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager_unittest.cc:113: }; Nit: DISALLOW_COPY_AND_ASSIGN https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:5101: +<histogram name="BudgetAPI.Reserve" enum="BooleanSuccess"> This seems to be adding a new top-level prefix in histogram names. This is generally discouraged unless you expect this will be used a lot for new metrics. Can this be nested under an existing prefix?
https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager.cc:136: UMA_HISTOGRAM_COUNTS_100("BudgetAPI.QueryBudget", budget[0]->budget_at); On 2016/11/29 16:45:35, Alexei Svitkine (slow) wrote: > Please refactor the code so the macro is only emitted once. Since each macro > expands to a bunch of code. Done. https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager_unittest.cc (right): https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager_unittest.cc:106: base::HistogramTester* GetHistogramTester() { return &histogram_tester_; } On 2016/11/29 16:45:35, Alexei Svitkine (slow) wrote: > Nit: histogram_tester() Done. https://codereview.chromium.org/2524533002/diff/70001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager_unittest.cc:113: }; On 2016/11/29 16:45:35, Alexei Svitkine (slow) wrote: > Nit: DISALLOW_COPY_AND_ASSIGN Done. https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:5101: +<histogram name="BudgetAPI.Reserve" enum="BooleanSuccess"> On 2016/11/29 16:45:35, Alexei Svitkine (slow) wrote: > This seems to be adding a new top-level prefix in histogram names. > > This is generally discouraged unless you expect this will be used a lot for new > metrics. Can this be nested under an existing prefix? Currently, the API is only provided for silent push, however we intend to add support for other background processing in the future. I would imagine that we would eventually add another 3-4 metrics under this heading. we could, conceivably, move the metric under PushMessaging, but that only makes sense for the silent push case, and would be very odd when we add other functionality.
https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:5101: +<histogram name="BudgetAPI.Reserve" enum="BooleanSuccess"> On 2016/11/30 11:31:52, harkness wrote: > On 2016/11/29 16:45:35, Alexei Svitkine (slow) wrote: > > This seems to be adding a new top-level prefix in histogram names. > > > > This is generally discouraged unless you expect this will be used a lot for > new > > metrics. Can this be nested under an existing prefix? > > Currently, the API is only provided for silent push, however we intend to add > support for other background processing in the future. > > I would imagine that we would eventually add another 3-4 metrics under this > heading. we could, conceivably, move the metric under PushMessaging, but that > only makes sense for the silent push case, and would be very odd when we add > other functionality. Since this is a web platform API, how about Blink.BudgetAPI.*? https://codereview.chromium.org/2524533002/diff/90001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/90001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager.cc:135: : budget[0]->budget_at; Nit: This looks a bit messy to me. How about: double budget_at = 0; if (error == blink::mojom::BudgetServiceErrorType::NONE) budget_at = budget[0]->budget_at;
https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2524533002/diff/70001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:5101: +<histogram name="BudgetAPI.Reserve" enum="BooleanSuccess"> On 2016/12/01 18:25:10, Alexei Svitkine wrote: > On 2016/11/30 11:31:52, harkness wrote: > > On 2016/11/29 16:45:35, Alexei Svitkine (slow) wrote: > > > This seems to be adding a new top-level prefix in histogram names. > > > > > > This is generally discouraged unless you expect this will be used a lot for > > new > > > metrics. Can this be nested under an existing prefix? > > > > Currently, the API is only provided for silent push, however we intend to add > > support for other background processing in the future. > > > > I would imagine that we would eventually add another 3-4 metrics under this > > heading. we could, conceivably, move the metric under PushMessaging, but that > > only makes sense for the silent push case, and would be very odd when we add > > other functionality. > > Since this is a web platform API, how about Blink.BudgetAPI.*? Good suggestion, I've updated it to Blink.BudgetAPI.* https://codereview.chromium.org/2524533002/diff/90001/chrome/browser/budget_s... File chrome/browser/budget_service/budget_manager.cc (right): https://codereview.chromium.org/2524533002/diff/90001/chrome/browser/budget_s... chrome/browser/budget_service/budget_manager.cc:135: : budget[0]->budget_at; On 2016/12/01 18:25:10, Alexei Svitkine wrote: > Nit: This looks a bit messy to me. How about: > > double budget_at = 0; > if (error == blink::mojom::BudgetServiceErrorType::NONE) > budget_at = budget[0]->budget_at; Done.
lgtm
The CQ bit was checked by harkness@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org Link to the patchset: https://codereview.chromium.org/2524533002/#ps110001 (title: "Reanmed BudgetAPI UMA to Blinklink.BudgetAPI and updated budget_at assignment.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...) chromeos_amd64-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...) linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by harkness@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by harkness@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org, asvitkine@chromium.org Link to the patchset: https://codereview.chromium.org/2524533002/#ps130001 (title: "Rebase and switch to using STL types to match mojo changes.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 130001, "attempt_start_ts": 1480927650437230,
"parent_rev": "6746109c501171a0b5f8913b314c9d895fb4d8d0", "commit_rev":
"3d49f2a29f6cc7e91edbe92934b59cdec60e7b32"}
Message was sent while issue was closed.
Committed patchset #8 (id:130001)
Message was sent while issue was closed.
Description was changed from ========== Added UMA for usage of BudgetAPI calls. Although there are metrics for the budget and SES at the time that budget is consumed, there isn't currently any tracking for which events in the budget system come via the Budget API interface. This adds two new metrics, to track queries and reserve requests. It also adds some basic testing to ensure the metrics are being recorded. BUG=617971 ========== to ========== Added UMA for usage of BudgetAPI calls. Although there are metrics for the budget and SES at the time that budget is consumed, there isn't currently any tracking for which events in the budget system come via the Budget API interface. This adds two new metrics, to track queries and reserve requests. It also adds some basic testing to ensure the metrics are being recorded. BUG=617971 Committed: https://crrev.com/2b5939812baa7c97c1d908b10150d7ad7109dc31 Cr-Commit-Position: refs/heads/master@{#436249} ==========
Message was sent while issue was closed.
Patchset 8 (id:??) landed as https://crrev.com/2b5939812baa7c97c1d908b10150d7ad7109dc31 Cr-Commit-Position: refs/heads/master@{#436249} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
