diff options
author | gavinp@chromium.org <gavinp@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-10 10:05:26 +0000 |
---|---|---|
committer | gavinp@chromium.org <gavinp@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-10 10:05:26 +0000 |
commit | e6c0633bada8818d20008300e2efcba81c67788f (patch) | |
tree | 47075a8778f0d3b53e3315bda10c99f8d634c6b5 /build/install-build-deps.sh | |
parent | 79df93870043072b0f2bff6166b7070d9b028bad (diff) | |
download | chromium_src-e6c0633bada8818d20008300e2efcba81c67788f.zip chromium_src-e6c0633bada8818d20008300e2efcba81c67788f.tar.gz chromium_src-e6c0633bada8818d20008300e2efcba81c67788f.tar.bz2 |
Add NEWCACHE method to IndexInitializeMethod histogram.
UMA histograms don't distinguish creating a new cache from rebuilding a new index due to a preexisting stale or corrupt index. This means that it's difficult to see how often the cache is restoring with a bad index, vs a new cache being created; and since lots of users start up the new simple backend everyday, we can't track bad indexes.
This is not great; index restore/rebuild is slow, and we want to make sure it happens very rarely in practice.
This adds a new value to the INITIALIZE_METHOD, so we can separate new caches from rebuilding indexes in existing caches.
As well, we track how many entries are in our new index. This isn't expected to always be zero, since entries can be created asynchronously while or before the index is rebuilding. But it does provide a sanity check in case index files are being erased (not expected), as large values would show we're sometimes missing index files on mature caches.
R=stevet,asvitkine@chromium.org
BUG=None
Review URL: https://chromiumcodereview.appspot.com/14890014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@199447 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'build/install-build-deps.sh')
0 files changed, 0 insertions, 0 deletions