OLD | NEW |
(Empty) | |
| 1 # Bisecting Performance Regressions |
| 2 |
| 3 [TOC] |
| 4 |
| 5 ## What are performance bisects? |
| 6 |
| 7 The perf tests on chromium's continuous build are very long-running, so we |
| 8 cannot run them on every revision. Further, separate repositories like v8 |
| 9 and skia sometimes roll multiple performance-sensitive changes into chromium |
| 10 at once. For these reasons, we need a tool that can bisect the root cause of |
| 11 performance regressions over a CL range, descending into third_party |
| 12 repositories as necessary. This is what the performance bisect bots do. |
| 13 |
| 14 The team is currently working on a new version of performance biscect called |
| 15 [pinpoint](https://docs.google.com/document/d/1FKPRNU2kbPJ15p6XHO0itCjYtfvCpGt2I
HblriTX1tg/edit) |
| 16 |
| 17 ## Starting a perf bisect |
| 18 |
| 19 Performance bisects are tightly integrated with the |
| 20 [Chrome Performance Dashboard](https://chromeperf.appspot.com/alerts) and |
| 21 [monorail](https://bugs.chromium.org/p/chromium/issues/list). Users kick off |
| 22 perf bisects on the perf dashboard and view results in monorail. |
| 23 |
| 24 You can kick off a perf bisect anywhere you see a performance graph on the perf |
| 25 dashboard (except for some tests which don't bisect, because they do not run on |
| 26 the [chromium.perf waterfall](https://build.chromium.org/p/chromium.perf/waterfa
ll)). |
| 27 |
| 28 ### To get to a graph, use one of the following methods: |
| 29 |
| 30 * From a perf sheriff-filed bug, follow the link in #1 that looks like |
| 31 `https://chromeperf.appspot.com/group_report?bug_id=XXXXXX`. Check the |
| 32 boxes next to alerts in the table to display graphs. |
| 33 * From the [alerts page](https://chromeperf.appspot.com/alerts), check the |
| 34 box next to an alert and click the `Graph` button. |
| 35 * From the [report page](https://chromeperf.appspot.com/report), use the menu |
| 36 to navigate to the graph you want. |
| 37 |
| 38 ### To kick off a bisect from the graph: |
| 39 |
| 40  |
| 41  |
| 42 |
| 43 1. Click on a data point in the graph. |
| 44 2. In the tooltip that shows up, click the `BISECT` button. |
| 45 3. Make sure to enter a Bug ID in the dialog that comes up. |
| 46 4. Click the `START BISECT` button. |
| 47 |
| 48 ### What are all the boxes in the form? |
| 49 |
| 50 * **Bisect bot**: The name of the configuration in the perf lab to bisect on. |
| 51 This has been prefilled to match the bot that generated the graph as |
| 52 closely as possible. |
| 53 * **Metric**: The metric of the performance test to bisect. This defaults to |
| 54 the metric shown on the graph. It shows a list of other related metrics |
| 55 (for example, if average page load time increased, the drop down will show |
| 56 a list of individual pages which were measured). |
| 57 * **Story filter**: This is a flag specific to |
| 58 [telemetry](https://github.com/catapult-project/catapult/blob/master/telemet
ry/README.md). |
| 59 It tells telemetry to only run a specific test case, instead of running all |
| 60 the test cases in the suite. This dramatically reduces bisect time for |
| 61 large test suites. The dashboard will prefill this box based on the graph |
| 62 you clicked on. If you suspect that test cases in the benchmark are not |
| 63 independent, you can try bisecting with this box cleared. |
| 64 * **Bug ID**: The bug number in monorail. It's very important to fill in |
| 65 this field, as this is where bisect results will be posted. |
| 66 * **Earlier revision**: The chromium commit pos to start bisecting from. This |
| 67 is prefilled by the dashboard to the start of the revision range for the |
| 68 point you clicked on. You can set it to an earlier commit position to |
| 69 bisect a larger range. |
| 70 * **Later revision**: The chromium commit pos to bisect to. This is prefilled |
| 71 by the dashboard to the end of the revision range for the point you clicked |
| 72 on. You can set it to a later commit pos to bisect a larger range. |
| 73 * **Launch on staging bots**: This is an internal feature, which allows the |
| 74 bisect team to launch a bisect on a test configuration. You likely don't |
| 75 want to check this box unless instructed by the bisect team. |
| 76 * **Bisect mode**: use "mean" to bisect the mean value of the performance |
| 77 test. See below for "return_code". |
| 78 |
| 79 ## Bisecting test failures |
| 80 |
| 81 The perf bisect bots can also be used to bisect performance test failures. |
| 82 See details in [Triaging Data Stoppage Alerts](triaging_data_stoppage_alerts.md)
. |
| 83 |
| 84 ## Interpreting the results |
| 85 |
| 86 The bisect bot will output a comment on the bug you input into the dialog when |
| 87 bisection is complete. See the |
| 88 [Understanding the Bisect Results](addressing_performance_regressions.md#Underst
anding-the-bisect-results) |
| 89 section of the Addressing Performance Regressions doc for details on how to |
| 90 interpret the results. |
| 91 |
| 92 ## Getting more debugging data |
| 93 |
| 94 The bisect outputs some additional data which might be useful for really tough |
| 95 regressions or confusing results. |
| 96 |
| 97 ### Traces |
| 98 |
| 99 Chrome traces are generated by most bisects and uploaded to cloud storage, but |
| 100 they're not very visible in the UI. We plan to address this in |
| 101 [pinpoint](https://docs.google.com/document/d/1FKPRNU2kbPJ15p6XHO0itCjYtfvCpGt2I
HblriTX1tg/edit), |
| 102 but in the short term here are the steps to get the traces from a bisect: |
| 103 |
| 104 1. The bisect comment should have a "Debug Info" link that looks like this: |
| 105 `https://chromeperf.appspot.com/buildbucket_job_status/8980436717323504240` |
| 106 Click it. |
| 107 2. In the debug info, you should see a "Buildbot link" that looks like this: |
| 108 `https://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexu
s7_perf_bisect/builds/4097` |
| 109 Click it. |
| 110 3. There will be several steps on the buildbot status page named "Bisecting |
| 111 Revision". Each has an annotation like "Revision: chromium@474894" so you |
| 112 can tell which revision it ran. Pick the commit position you want the |
| 113 trace from (usually the one at your CL and the one immediately before). |
| 114 Click the arrow by "> Nested step(s) for: Bisecting revision..." on those |
| 115 steps. |
| 116 4. In the nested steps, you'll see several steps titled "Bisecting |
| 117 revision.Performance Test X of Y". These are the actual perf test runs. |
| 118 Click the "stdout" link for one of these steps. |
| 119 5. In the output, do a text search for "View generated trace files online" |
| 120 and you'll see a link to a trace that looks like this: |
| 121 `https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-ou
tput/o/trace-file-id_0-2017-05-05_05-41-49-83206.html` |
| 122 |
| 123 Here are some screenshots showing what to click on: |
| 124 |
| 125  |
| 126  |
OLD | NEW |