Changes in WebView's memory footprint due to TsProxy |
||
Issue descriptionEnabling TsProxy in Telemetry (f5d731cca69d998593f42ab79d8eaa26380d7fe3) caused several memory measurements to shift, with most high-level metrics going down, for example: https://chromeperf.appspot.com/report?sid=ca7820bb825076ad923576e3d430dfb4e40d44fa3ae305b25d447175b6bc7f6c&start_rev=1473715838&end_rev=1473927297 Memory drops by ~1.3MB when enabling TsProxy, and comes back to its previous baseline after reverting that CL. I am guessing this could be an artificial "improvement" due to the way the traffic is being shaped with TsProxy? Anyway, I want to make sure we understand why memory goes down and that, e.g., it's not because we're failing to load some resources. Interestingly, Chrome's memory usage does not seem to be affected by this. To help investigations here are a couple of traces: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_14-2016-09-14_00-44-58-41135.html (without TsProxy) https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_14-2016-09-14_01-44-00-17452.html (with TsProxy)
,
Sep 15 2016
What is TsProxy?
,
Sep 15 2016
Matt: tsproxy (https://github.com/WPO-Foundation/tsproxy) is a traffic shaping tool which Patrick built using SOCKS5 proxy. Recently, we change telemetry from using "--testing-fixed-http-port=.." & "--testing-fixed-https-port=.." flags for running test against the local web-page-replay server to using "--proxy-server==..." with ts_proxy sits between the browser & WPR.
,
Sep 15 2016
SOCKS5 traffic-shaping proxy (though in this testing the traffic-shaping is disabled so it is basically in passthrough mode). I'm sure there are a bunch of plumbing changes through net when going through a proxy pool (though the connection management should be similar). I also wouldn't be surprised if there were subtle timing changes. Off the top of my head one thing that changes is the DNS lookup since the lookups are done by the proxy though it's hard to say what (if any) impact that would have on working set.
,
Sep 15 2016
Proxy pools have a lower limit on number of sockets, so could be running into that. I wouldn't think fewer DNS lookups would make much difference - DNS cache entries aren't too big. No idea why that would show up on WebView but not Chrome, though, unless Chrome by is making fewer connections, or closing the ones it does make, for some reason.
,
Oct 25 2016
Hmm, I ran a test again with a more recent WebView version (at commit 423736-a41), with/without TsProxy [1] and the results [2] do not reproduce the decrease in memory usage. In fact the memory usage goes up a bit this time. Not sure exactly what happened when running this on the bot. But will have to close this one as "unable to reproduce". [1]: revert CL: https://codereview.chromium.org/2445693002/ [2]: https://x20web.corp.google.com/~perezju/memory_infra/cr647171/results.html |
||
►
Sign in to add a comment |
||
Comment 1 by nedngu...@google.com
, Sep 15 2016