Investigate shrinking AsyncResourceHandler's 512k ring buffer. |
||||||||
Issue descriptionAsyncResourceHandler uses a 512k buffer of shared memory to pass data to the renderer, which we could consider shrinking. Most requests are for less than 512k, but unfortunately, due to compression, we often don't know their actual size in advance (Though in some cases we do, so could use the exact resource size). We could consider starting out with a smaller buffer and then growing it if it reaches capacity, up to a limit, though that gets more complicated. It's also possible that shrinking it for small resources isn't useful. It only exists from the time we start reading the body of a response until the end, which, for small resources, is probably not a long time, since they're usually sent by the server at about the same time as the headers. I think the way to start is to investigate how many of these we have around at once in the case of slow connections (Through experimentation? UMA?), to see how much of a problem this is.
,
Jan 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/18491e4f87ce2e5e53f64dad2a3da0a1f5688e01 commit 18491e4f87ce2e5e53f64dad2a3da0a1f5688e01 Author: maksim.sisov <maksim.sisov@intel.com> Date: Fri Jan 20 08:19:55 2017 Add UMA histograms to AsyncResourceHandler to track content size. This CL add UMA histograms, which are used to record how many times content size is known and if it is precise enough to be used. What is more, total size of read body is compared to the size of allocated buffer, which is 512kb, to record how many times its size is less than buffer's size. BUG= 622363 Review-Url: https://codereview.chromium.org/2624123002 Cr-Commit-Position: refs/heads/master@{#445016} [modify] https://crrev.com/18491e4f87ce2e5e53f64dad2a3da0a1f5688e01/content/browser/loader/async_resource_handler.cc [modify] https://crrev.com/18491e4f87ce2e5e53f64dad2a3da0a1f5688e01/content/browser/loader/async_resource_handler.h [modify] https://crrev.com/18491e4f87ce2e5e53f64dad2a3da0a1f5688e01/tools/metrics/histograms/histograms.xml
,
Jan 20 2017
,
Feb 6 2017
,
Mar 3 2017
,
Mar 3 2017
UMA shows that ~58% is in the EQ_RESPONSE_BODY bucket, and ~35% is in the UNKNOWN bucket. base::SharedMemory is yet not reported in memory-infra. It's being worked on ( Issue 604726 ). Once we have that, I think we will be in a better shape to determine whether the 512KB buffer is a problem.
,
Apr 20 2017
,
Apr 20 2017
Matt: is this worth investigating further given the mojo work mentioned in the other thread?
,
Apr 20 2017
I don't think it is (May be worth experimenting with the mojo buffer parameters, but that seems like another issue)
,
Apr 21 2017
FWIW there is some possibly related discussion about this in Issue 294367
,
Mar 9 2018
Issue 820247 has been merged into this issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by maksim.s...@intel.com
, Jan 9 2017