New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 698211 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Dec 2017
Cc:
perezju@chromium.org
█ nednguyen@chromium.org
sullivan@chromium.org
nedngu...@google.com
█ benhenry@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature



Sign in to add a comment

Investigate efficacy of alerting on individual "low-level" stories/metrics

Project Member Reported by benhenry@chromium.org, Mar 3 2017 
Looking at this graph:
https://chromeperf.appspot.com/report?sid=33b8c61d30ab6a80e08ce433a1ba98b151bcbe263b758e72bb1218d8add4d0ca&start_rev=1486119399&end_rev=1488528859

There is a lesser metric, yet all of the pages have a similar regression of around 1MB. What would happen if we set up alerting on all graphs over some threshold defined by the benchmark? In this case, I think 800kB would be a good place to start, and we could tune it over time. I had to file a bug and kick off a bisect, but we should include this in the sheriffing rotation.

Comment 1 by nedngu...@google.com, Mar 6 2017

Cc: nedngu...@google.com
Owner: ----
Status: Unconfirmed (was: Assigned)
Ben: the risk of alerting on all graphs is that sometimes people can move memory from one component to another, hence we end up having false alert with this model. 

For this particular example: are you seeing the total memory metric having a similar regression?

Unassign myself because it's unclear what to do about this bug yet.

Comment 2 by benhenry@chromium.org, Mar 6 2017 

Is it acceptable to move ~1MB from one component to another? That seems like a large bit of memory for something that we'd be un-aware of.

Comment 3 by nedngu...@google.com, Mar 6 2017 

Given we already have a lot of top level perf regressions to deal with & a "move regression" does not affect the user experience, I don't think perf-sheriffs should prioritize dealing with these. 

Having said that, I do think that it is still useful to keep track of how memory are breakdown in Chrome, but we don't need to do this on a CL-by-CL basis. A quarter report of memory breakdown in Chrome is probably enough for this use case.

Comment 4 by benhenry@chromium.org, Dec 12 2017

Status: WontFix (was: Unconfirmed)
Bisect unable to find culprit. This exists in stable. Ignoring.
►

Sign in to add a comment