Improve record_wpr script's stability |
||||||
Issue descriptionIt appears the new .wprgo file is essentially an empty archive. Detailed notes: Breakout from discussion on: https://chromium-review.googlesource.com/c/chromium/src/+/648349 I'm trying to re-record the top 25 pageset with: % tools/perf/record_wpr --story top25_page_set rasterize_and_record_micro_top25 Note that sadly you also have to first manually apply: https://chromium-review.googlesource.com/c/chromium/src/+/648252 and hack two files as noted in that change description, and comment out the disabled Gmail and CNN story entries in tools/perf/benchmarks/rasterize_and_record_micro.py if you want to be thorough. It's probably actually ok for the purposes of this bug if some stories fail, as long as some succeed. This page set has already been previously converted to WPRGo. After running, I see a new file as: tools/perf/page_sets/data/top_25_008.wprgo.sha1 And the entries in tools/perf/page_sets/data/top_25.json are updated to refer to the new _008 file. However, the outputted .wprgo file is only 36 bytes: % wc -c tools/perf/page_sets/data/top_25_008.wprgo 36 tools/perf/page_sets/data/top_25_008.wprgo And, even if it did contain the correct content, I'm not sure how to upload it to the cloud. Passing '--upload' to record_wpr doesn't seem to output anything to inform me re: whether it's uploading or, if it tried, if it succeeded.
,
Sep 1 2017
Could it be because I'm using content-shell? Let me try with chrome. (WARNING) 2017-09-01 16:42:54,980 browser_finder.FindBrowser:81 --browser omitted. Using most recent local build: content-shell-release
,
Sep 2 2017
Yeah, it writes the correct file data with a Chrome binary. Probably no dev tools API with content shell. Well, I'll repurpose this bug into a P3 for us to consider having the record_wpr script output an error or info message or something to let the user know (a) if writing/getting the data fails, and/or (b) that content shell doesn't work, or dev tools API isn't available, or something.
,
Sep 4 2017
Assign to Ashely to backlog this. We probably get to this once benchmarks are a lot more stable.
,
Sep 15 2017
Chatted offline with victor, an idea we can do to stabilize the benchmark further is to ignore webpage login flow during benchmark replay time. Rough idea, Page class will have Login hook, then: if record: Page.Login() Page.Navigate(<main url>) ... else: Page.Navigate(<main url>) ... This not only reduce the cycle time of benchmark but also mitigate the risk of breakage when the login code need to be updated.
,
Jan 16
,
Jan 16
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by wkorman@chromium.org
, Sep 1 2017