Reduce "false positive" in preconnect rates.

Histograms suggest that all too often, we create a preconnection
for an omnibox entry (for a search URL), and then the 
connection goes unused.  This probably happens when
the first few letters of an URL are typed, but are
misconstrued to be a search URL.  I added code that
requires a sequence of consecutive assertions by the
omnibox that the URL is preconnectable (i.e., is a
search URL).  This will give me something to tune, but
this CL pulls a number out of teh air, in hopes of
getting some baseline.

I also noticed that the unused connections courtesy 
of speculative subresource preconnection was higher
than expected, and the number of cases where we
didn't bother to even do a pre-resolut1ion for
a subresource was higher than expected.  It used
to be that I did sub-resource pre-resolution for
all 8 learned speculative names.  Now that we
have preconnection as an alternative, I extended
the count to 10 names learned, but put in a
threshold for expected connections.  I adjusted
the thresholds to increase the amount of
pre-resolution, and decrease the amount of
preconection.  I really need an A/B test
to optimize these, but initially I wanted
to get a feel for what happens with different
limits.

BUG=42694
r=mbelshe
Review URL: http://codereview.chromium.org/3126012

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56538 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions