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

Issue 825612 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

6.3%-47.9% regression in blink_perf.owp_storage at 545358:545550

Project Member Reported by sullivan@chromium.org, Mar 25 2018

Issue description

Note there is also an improvement in BlobReader::ReadBytesItem at this range: https://chromeperf.appspot.com/group_report?sid=44357ffbc30ec457a53f9aa369c09c71f837fd9b6a5b35f3aee82a2d63c30d49
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Mar 25 2018

All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=825612

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=d073269b05df012b89735220dcdf832242a4ea66472fdf8fa5b14c26081a52fd


Bot(s) for this bug's original alert(s):

android-one
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Mar 26 2018

Cc: eyaich@google.com eyaich@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/1197413d440000

Disabling blink_perf.owp_storage on Android one by eyaich@google.com
https://chromium.googlesource.com/chromium/src/+/6ccc199f6f18cfecb64e7fd8ff211865940591a9

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions
Owner: nedngu...@google.com
Ned, can you help triage this? It looks like blink_perf.owp_storage was disabled in the middle of the "regression" range--why is it still producing data?
Owner: charliea@chromium.org
Looks like the disabling logic doesn't do anything. The test is still running on Android One (https://ci.chromium.org/buildbot/chromium.perf/Android%20One%20Perf/1354)
I think what happened here is that Emily disabled one particular story (blink_perf.owp_storage/blob-perf-shm.html) in her CL. That story being disabled changed the monitored summary metric (Registry::RegisterBlob) and the bisect correctly identified that CL as being responsible.

As far as I can tell, this is working as intended with the bug being that we really shouldn't monitor summary metrics for this reason.
Cc: -eyaich@google.com nednguyen@chromium.org dmu...@chromium.org
Owner: simonhatch@chromium.org
Simon, can you work with the benchmark owner to help them figure out how we can stop monitoring these summary metrics?
I don't quite understand why we need to disable that metric?
Re #8: The failure in  bug 823357  was the reason for the disable.


re: #c7

Sure, although the line in the sheriffs config just blanket sets alerting on all blink_perf summary metrics. Maybe we should be getting all of those switched to per-page?
Per-page alerting works great for us. We don't need alerting on the sum of everything blink_perf.owp_storage
Checking in, so it's a bit cumbersome to switch JUST blink_perf.owp_storage to per-page alerting, since that means I'd have to enumerate all the other blink_perf tests. I can't specify

blink_perf.owp_storage/*/*
blink_perf.*(except owp_storage)/*

Ideally we'd just switch them all at once.
Owner: ----
Status: Available (was: Assigned)
Status: Untriaged (was: Available)
Available, but no owner or component? Please find a component, as no one will ever find this without one.

Sign in to add a comment