Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2403193002:
Precache: Optionally rank resources-to-precache globally. (Closed)
DescriptionPrecache: Optionally rank resources-to-precache globally.
Added a new global_ranking varation param to the experiment, default false. If
specified, the client will multiply each resource weight (a value [0,1]) from
the PrecacheManifest by the number of visits to that host -- the result being
an estimated likelihood of using that resource. The resources will then be
fetched in decreasing order of likelihood.
This allows hosts with vastly more visits to fetch more resources than hosts
with vastly fewer visits. It also allows mostly-useless resources to bubble
down and be replaced by resources for additional hosts.
In addition, added a couple new fields to PrecacheConfigurationSettings to
tweak its behavior:
- total_resources_count is a cap on the total number of resource URLs to fetch
- min_weight is a threshold on the minimum likelihood
In addition, a few things changed in behavior:
- manifests are fetched first, before any resources
- the PercentCompleted UMA is measured in % of resource URLs complete rather
than % of manifests complete
- resource ordering is preserved across pause/resume
BUG=654166
Committed: https://crrev.com/528a15b56652173bd822ea2a1123e6960ba4f255
Cr-Commit-Position: refs/heads/master@{#426350}
Patch Set 1 #
Total comments: 18
Patch Set 2 : Code readability improvements per bengr. #
Total comments: 10
Patch Set 3 : Extract QueueResourcesForFetch() and other cleanup. #Patch Set 4 : Log 0/0 to overflow bucket instead of 0 bucket. #Patch Set 5 : Move global_ranking from variation param to proto. #Patch Set 6 : Rebase. #
Messages
Total messages: 31 (15 generated)
The CQ bit was checked by twifkak@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
twifkak@chromium.org changed reviewers: + bengr@chromium.org, jamartin@chromium.org, rajendrant@chromium.org
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Message was sent while issue was closed.
Description was changed from ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume NOTE TO REVIEWERS: Currently the weight is "resource.weight * number of visits to host". However, http://crbug.com/638423 suggests an additional threshold based on the % of visits to a host. Should I add that threshold in this commit, a future one, or never? NOTE 2: This required some tweaks to the async code in order to preserve ordering in PrecacheUnfinishedWork. If you know something about that code, I'd appreciate any extra attention you could give those parts. BUG=654166 ========== to ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume NOTE TO REVIEWERS: Currently the weight is "resource.weight * number of visits to host". However, http://crbug.com/638423 suggests an additional threshold based on the % of visits to a host. Should I add that threshold in this commit, a future one, or never? NOTE 2: This required some tweaks to the async code in order to preserve ordering in PrecacheUnfinishedWork. If you know something about that code, I'd appreciate any extra attention you could give those parts. BUG=654166 ==========
I'm not convinced we should do the host-level threshold on the % of visits. http://crbug.com/638423 didn't consider the weight of the resources and, if we understand resource.weight * num_host_visits as the expected number of times that resource will be required, then I think it should suffice to rank in decreasing order. Besides, you already have min_weight, which I think can make a smarter (yet less obvious) decision on what to keep. It should be enough to get rid of resources (and probably entire hosts) for which the manifests are not useful enough for that particular user.
On 2016/10/12 19:32:27, jamartin wrote: > I'm not convinced we should do the host-level threshold on the % of visits. > http://crbug.com/638423 didn't consider the weight of the resources and, if we > understand resource.weight * num_host_visits as the expected number of times > that resource will be required, then I think it should suffice to rank in > decreasing order. > > Besides, you already have min_weight, which I think can make a smarter (yet less > obvious) decision on what to keep. It should be enough to get rid of resources > (and probably entire hosts) for which the manifests are not useful enough for > that particular user. I agree completely with jamartin@
Description was changed from ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume NOTE TO REVIEWERS: Currently the weight is "resource.weight * number of visits to host". However, http://crbug.com/638423 suggests an additional threshold based on the % of visits to a host. Should I add that threshold in this commit, a future one, or never? NOTE 2: This required some tweaks to the async code in order to preserve ordering in PrecacheUnfinishedWork. If you know something about that code, I'd appreciate any extra attention you could give those parts. BUG=654166 ========== to ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume NOTE TO REVIEWERS: This required some tweaks to the async code in order to preserve ordering in PrecacheUnfinishedWork. If you know something about that code, I'd appreciate any extra attention you could give those parts. BUG=654166 ==========
On 2016/10/14 21:22:18, bengr wrote: > On 2016/10/12 19:32:27, jamartin wrote: > > I'm not convinced we should do the host-level threshold on the % of visits. > > http://crbug.com/638423 didn't consider the weight of the resources and, if we > > understand resource.weight * num_host_visits as the expected number of times > > that resource will be required, then I think it should suffice to rank in > > decreasing order. > > > > Besides, you already have min_weight, which I think can make a smarter (yet > less > > obvious) decision on what to keep. It should be enough to get rid of resources > > (and probably entire hosts) for which the manifests are not useful enough for > > that particular user. > > I agree completely with jamartin@ OK, thanks for your feedback! I've removed my question from the CL description, but for posterity, it was pretty much the interrogative form of Jose's first sentence.
https://codereview.chromium.org/2403193002/diff/1/components/precache/content... File components/precache/content/precache_manager.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/content... components/precache/content/precache_manager.cc:151: unfinished_work->set_start_time(base::Time::Now().ToInternalValue()); Why is start time being set here too? https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:380: VLOG(6) << "Percent completed: " << percent_completed; Do you need these VLOG statements? https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:453: for (const auto& top_host : top_hosts_fetching_) { Remove curly braces. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:456: for (const auto& top_host : top_hosts_to_fetch_) { Remove curly braces. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:525: VLOG(3) << "Fetching " << top_host.manifest_url; Do we need the VLOG (here and below)? https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:725: if (!global_ranking_) Add curly braces. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher.h (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.h:74: GURL url; // The resource being requested. Nit: these comments aren't lined up. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher_unittest.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher_unittest.cc:1020: const size_t kNumResources = kMaxParallelFetches + 5; Please add comments to explain the magic of "5" here and "7" below.
https://codereview.chromium.org/2403193002/diff/1/components/precache/content... File components/precache/content/precache_manager.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/content... components/precache/content/precache_manager.cc:151: unfinished_work->set_start_time(base::Time::Now().ToInternalValue()); On 2016/10/14 21:52:19, bengr wrote: > Why is start time being set here too? The first one is what happens on a fresh precache run -- i.e. the previous one succeeded and there is no unfinished work. The second one is what happens if a precache takes longer than 6 hours to complete (via pause/resume), and essentially gives up and starts over. I've simplified the code to eliminate the duplication. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:380: VLOG(6) << "Percent completed: " << percent_completed; On 2016/10/14 21:52:19, bengr wrote: > Do you need these VLOG statements? They were very helpful during debugging, but I can delete if you'd prefer. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:453: for (const auto& top_host : top_hosts_fetching_) { On 2016/10/14 21:52:19, bengr wrote: > Remove curly braces. Done. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:456: for (const auto& top_host : top_hosts_to_fetch_) { On 2016/10/14 21:52:19, bengr wrote: > Remove curly braces. Done. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:525: VLOG(3) << "Fetching " << top_host.manifest_url; On 2016/10/14 21:52:19, bengr wrote: > Do we need the VLOG (here and below)? This VLOG is not new. The ones I added are all --v=6 and higher. But ditto above; incredibly helpful during unittest debugging, but easy to add again later, so say the word and I'll nuke 'em. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:725: if (!global_ranking_) On 2016/10/14 21:52:19, bengr wrote: > Add curly braces. Done. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher.h (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.h:74: GURL url; // The resource being requested. On 2016/10/14 21:52:19, bengr wrote: > Nit: these comments aren't lined up. Believe it or not, that's what clang-format produces. I've cheated and removed "An" so the last comment fits in 80 chars after being aligned. https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher_unittest.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher_unittest.cc:1020: const size_t kNumResources = kMaxParallelFetches + 5; On 2016/10/14 21:52:19, bengr wrote: > Please add comments to explain the magic of "5" here and "7" below. OK, did my best. I don't fully understand this test, either (e.g. my new TODO below).
https://chromiumcodereview.appspot.com/2403193002/diff/1/components/precache/... File components/precache/core/precache_fetcher.cc (right): https://chromiumcodereview.appspot.com/2403193002/diff/1/components/precache/... components/precache/core/precache_fetcher.cc:380: VLOG(6) << "Percent completed: " << percent_completed; On 2016/10/14 22:41:45, twifkak wrote: > On 2016/10/14 21:52:19, bengr wrote: > > Do you need these VLOG statements? > > They were very helpful during debugging, but I can delete if you'd prefer. Chromium style is to remove logging statements, so please do. See: https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md... https://chromiumcodereview.appspot.com/2403193002/diff/20001/components/preca... File components/precache/core/precache_fetcher.cc (right): https://chromiumcodereview.appspot.com/2403193002/diff/20001/components/preca... components/precache/core/precache_fetcher.cc:57: // The maximum number of URLFetcher requests that can be on flight in parallel. nit: on -> in https://chromiumcodereview.appspot.com/2403193002/diff/20001/components/preca... components/precache/core/precache_fetcher.cc:374: num_total_resources == 0 I wonder if we should be reporting num_total_resources == 0 separately. https://chromiumcodereview.appspot.com/2403193002/diff/20001/components/preca... components/precache/core/precache_fetcher.cc:523: VLOG(3) << "Fetching " << top_host.manifest_url; Please remove all VLOG statements. https://chromiumcodereview.appspot.com/2403193002/diff/20001/components/preca... components/precache/core/precache_fetcher.cc:756: // Done fetching manifests. Now sort resources_to_rank_ into Not a requirement, but this seems like it's getting a bit unwieldy. Could you factor out the global ranking stuff? At the very least it will make it easier to test.
Description was changed from ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume NOTE TO REVIEWERS: This required some tweaks to the async code in order to preserve ordering in PrecacheUnfinishedWork. If you know something about that code, I'd appreciate any extra attention you could give those parts. BUG=654166 ========== to ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume BUG=654166 ==========
https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... File components/precache/core/precache_fetcher.cc (right): https://codereview.chromium.org/2403193002/diff/1/components/precache/core/pr... components/precache/core/precache_fetcher.cc:380: VLOG(6) << "Percent completed: " << percent_completed; On 2016/10/18 18:57:20, bengr wrote: > On 2016/10/14 22:41:45, twifkak wrote: > > On 2016/10/14 21:52:19, bengr wrote: > > > Do you need these VLOG statements? > > > > They were very helpful during debugging, but I can delete if you'd prefer. > > Chromium style is to remove logging statements, so please do. See: > https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md... > Done. https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... File components/precache/core/precache_fetcher.cc (right): https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... components/precache/core/precache_fetcher.cc:57: // The maximum number of URLFetcher requests that can be on flight in parallel. On 2016/10/18 18:57:20, bengr wrote: > nit: on -> in Done. https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... components/precache/core/precache_fetcher.cc:374: num_total_resources == 0 On 2016/10/18 18:57:20, bengr wrote: > I wonder if we should be reporting num_total_resources == 0 separately. I'm amenable to that. My intuition is that this is small, but I don't have any evidence. How about the overflow bucket? Currently unused. https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... components/precache/core/precache_fetcher.cc:523: VLOG(3) << "Fetching " << top_host.manifest_url; On 2016/10/18 18:57:20, bengr wrote: > Please remove all VLOG statements. Done. https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... components/precache/core/precache_fetcher.cc:756: // Done fetching manifests. Now sort resources_to_rank_ into On 2016/10/18 18:57:20, bengr wrote: > Not a requirement, but this seems like it's getting a bit unwieldy. Could you > factor out the global ranking stuff? At the very least it will make it easier to > test. Okay, I extracted the inside of this if statement into a function, extracted a ResourceWeight() function, and removed the `if (!global_ranking)` above, so top_resources_count applies regardless. Should feel less spidery now.
lgtm https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... File components/precache/core/precache_fetcher.cc (right): https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... components/precache/core/precache_fetcher.cc:374: num_total_resources == 0 On 2016/10/18 19:52:27, twifkak wrote: > On 2016/10/18 18:57:20, bengr wrote: > > I wonder if we should be reporting num_total_resources == 0 separately. > > I'm amenable to that. My intuition is that this is small, but I don't have any > evidence. How about the overflow bucket? Currently unused. sgtm
Thanks for the review! I'll send to CQ later today. https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... File components/precache/core/precache_fetcher.cc (right): https://codereview.chromium.org/2403193002/diff/20001/components/precache/cor... components/precache/core/precache_fetcher.cc:374: num_total_resources == 0 On 2016/10/18 21:50:31, bengr wrote: > On 2016/10/18 19:52:27, twifkak wrote: > > On 2016/10/18 18:57:20, bengr wrote: > > > I wonder if we should be reporting num_total_resources == 0 separately. > > > > I'm amenable to that. My intuition is that this is small, but I don't have any > > evidence. How about the overflow bucket? Currently unused. > > sgtm Done.
Manual testing looks good. In patch set 5, made global_ranking a field in the config proto rather than a variation param. This should be easier to keep track of, since all our other settings are in the proto.
The CQ bit was checked by twifkak@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from bengr@chromium.org Link to the patchset: https://codereview.chromium.org/2403193002/#ps80001 (title: "Move global_ranking from variation param to proto.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: ios-device on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...) ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
The CQ bit was checked by twifkak@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from bengr@chromium.org Link to the patchset: https://codereview.chromium.org/2403193002/#ps100001 (title: "Rebase.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume BUG=654166 ========== to ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume BUG=654166 ==========
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume BUG=654166 ========== to ========== Precache: Optionally rank resources-to-precache globally. Added a new global_ranking varation param to the experiment, default false. If specified, the client will multiply each resource weight (a value [0,1]) from the PrecacheManifest by the number of visits to that host -- the result being an estimated likelihood of using that resource. The resources will then be fetched in decreasing order of likelihood. This allows hosts with vastly more visits to fetch more resources than hosts with vastly fewer visits. It also allows mostly-useless resources to bubble down and be replaced by resources for additional hosts. In addition, added a couple new fields to PrecacheConfigurationSettings to tweak its behavior: - total_resources_count is a cap on the total number of resource URLs to fetch - min_weight is a threshold on the minimum likelihood In addition, a few things changed in behavior: - manifests are fetched first, before any resources - the PercentCompleted UMA is measured in % of resource URLs complete rather than % of manifests complete - resource ordering is preserved across pause/resume BUG=654166 Committed: https://crrev.com/528a15b56652173bd822ea2a1123e6960ba4f255 Cr-Commit-Position: refs/heads/master@{#426350} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/528a15b56652173bd822ea2a1123e6960ba4f255 Cr-Commit-Position: refs/heads/master@{#426350} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
