Issue metadata
Sign in to add a comment
|
77.5%-542.1% regression in loading.mobile at 451844:453053 |
||||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Mar 2 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8986218600637733744
,
Mar 3 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: android_nexus5X_perf_bisect Benchmark : loading.mobile Metric : timeToFirstContentfulPaint_avg/Regular-3G/http___www.ibicn.com Revision Result N chromium@451843 46676.7 +- 4477.23 21 good chromium@453053 47035.9 +- 1327.52 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...www.ibicn.com loading.mobile Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8986218600637733744 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5042008885821440 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Mar 3 2017
All these alerts are on N5X. Looks like a lot of devices were swapped out between runs: https://build.chromium.org/p/chromium.perf/builders/Android%20Nexus5X%20Perf%20%283%29/builds/3457 https://build.chromium.org/p/chromium.perf/builders/Android%20Nexus5X%20Perf%20%283%29/builds/3460 I will try another bisect, and if it fails to repro, close due to device swap.
,
Mar 3 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8986140108736629312
,
Mar 3 2017
Also cc-ing charliea, martiniss, nednguyen: I remember there was a very long page_cycler test run that we could not reproduce locally. I wonder if something like that is happening here? This is a huge regression that probably shouldn't be explained by a device swap, now that I look at the raw numbers.
,
Mar 3 2017
That is issue 678965. The fact that this regression only happens to 3G traffic-shaped page does sounds like there is something weird about how ts_proxy's traffic shaping work & the device setup. I suspect that ts_proxy's 3g shaping may be misbehaving here, possible due to ts_proxy process being descheduled by the OS?. Pat: do you think there a way for us to check that ts_proxy doesn't throttle network more than it should be? Maybe something like ts_proxy produce a trace file that shows how long did it the message took?
,
Mar 3 2017
If you run ts_proxy with -vvvv it will output a lot of debug information about each packet as it arrives and goes out but I don't know if telemetry passes the logs through or swallows stdout. I can modify it to log to a file if it would help. That said, I seriously doubt this regression is from something like descheduling. The regressions are from ~10 seconds going to 50 seconds and on the order of 3G shaping, dscheduling would be a rounding error. It almost feels like maybe the traffic isn't flowing correctly and something is timing out and falling back.
,
Mar 3 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: android_nexus5X_perf_bisect Benchmark : loading.mobile Metric : timeToFirstMeaningfulPaint_avg/Regular-3G/https___2048-opera-pwa.surge.sh_ Revision Result N chromium@451843 61537.9 +- 2697.26 21 good chromium@453053 61208.8 +- 3321.96 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=https...2048.opera.pwa.surge.sh. loading.mobile Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8986140108736629312 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5833757484908544 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Mar 6 2017
Patrick: adding an option that allows ts_proxy to log into a file will be very useful. We currently already using stdout for communicating between ts_proxy & telemetry, so use a different channel for logging will make it easier to investigate. I file a bug in https://github.com/WPO-Foundation/tsproxy/issues/13 for this issue.
,
Mar 11 2017
,
Mar 13 2017
,
Apr 11 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982655857824511968
,
Apr 11 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: android_nexus5X_perf_bisect Benchmark : loading.mobile Metric : timeToFirstContentfulPaint_avg/Regular-3G/http___www.ibicn.com Revision Result N chromium@451843 46761.6 +- 2213.18 21 good chromium@453053 46870.1 +- 2005.07 21 bad To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...www.ibicn.com loading.mobile Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8982655857824511968 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5042008885821440 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
May 4 2017
Closing as WontFix due to no regression being found.
,
Jan 16
,
Jan 16
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sullivan@chromium.org
, Mar 2 2017