Add Precache.Fetch.MinWeight UMA.

components/precache/core/proto/precache.proto

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 syntax = "proto2";
 
 package precache;
 
 // Chrome requires this.
 option optimize_for = LITE_RUNTIME;
 
 // Information about a cacheable resource to be precached.
 message PrecacheResource {
   // The URL of the resource. This field must always be present.
   optional string url = 1;
 
   // The tophost this resource corresponds to.
   optional string top_host_name = 2;
 
   // How important this resource is for the host. It ranges from 0.0 to 1.0.
   // Higher values mean more important.
   optional double weight_ratio = 3;
+
+  // How important this resource is for the client; a combination of
+  // weight_ratio and TopHost.visits. Populated only in PrecacheUnfinishedWork.

[bengr, 2017/02/24 20:58:54]

Does this also range from 0.0 to 1.0 with higher values being more important?
Say so.

[twifkak, 2017/02/25 01:13:40]

Done.

+  optional double weight = 4;

[jamartin, 2017/02/24 21:23:29]

This also depends on resource_weight_function, isn't it? If so, please say so.

[jamartin, 2017/02/24 21:23:29]

I'm wondering if it makes sense to have distinct weight_naive and
weight_geometric or a resource_weight_function enum specifying the kind of
weight. For instance, if we have users using both weight functions, the UMA is
going to be quite messy. I guess we are fine, since UMA would still allow us to
slice and dice and this proto is not meant for long-time storage, but it feels
wrong having the same proto field for two related but different things.

If you decide to have a fully identified weight, maybe the way would be to have
a submessage, so future changes are slightly less painful.

message Weight {
  optional ResourceWeightFunction function = 1;
  optional double weight = 2;
}

(or maybe weight_naive and weight_geometric?).

[twifkak, 2017/02/25 01:13:39]

I don't think that's necessary. resource_weight_function is configured in the
config URL, which is stable for a given field trial group. So we just need to
slice by group. Which we need to do anyways.

[twifkak, 2017/02/25 01:13:39]

Done.

 };
 
 message PrecacheManifestId {
   optional int64 id = 1;
 };
 
 // A manifest of cacheable resources to be precached for a specific host.
 message PrecacheManifest {
   // List of resources that we predict that the user will need if they are
   // likely to fetch the host.
@@ skipping 84 matching lines @@
     // days, given that weight_ratio is a probability that a visit to the host
     // will request a resource, and host_visits is an estimate of the number of
     // visits to the host in the next 30 days.
     FUNCTION_NAIVE = 0;
     // Models the probability of at least one request, given the same.
     FUNCTION_GEOMETRIC = 1;
   };
   optional ResourceWeightFunction resource_weight_function = 11
       [default = FUNCTION_NAIVE];
 };