SimpleCache: open with fewer seeks.

SimpleCache: open with fewer seeks.

There's usually no reason to read the file header before reading the
stream 0 (headers) data when opening a simple cache entry. By not doing
so, seeks in the critical path of the loading headers are reduced, which
should speed up http caching performance.

To be careful, the headers are still checked when the first read of data
(if any) is performed. This delays detecting hash collisions in the
cache, because the header data is required to compare keys (instead of
just hashes).

To compensate for the later key comparison, a SHA256 of the key is
stored as an optional prefix to the end of file record. This is used to
validate the key is correct before returning headers to the client.

Because the key checking logic is now totally migrated back into the
SimpleSynchronousEntry, we can return to reporting on key matching in
the SyncOpenResult histograms.

R=juliatuttle@chromium.org,asvitkine@chromium.org,rdsmith@chromium.org
BUG=611732
Review-Url: https://codereview.chromium.org/1977863003
Cr-Commit-Position: refs/heads/master@{#395083}
(cherry picked from commit 9f15f2258d7cae8cd12cb4ef7143ad648a958333)

Committed: https://chromium.googlesource.com/chromium/src/+/3b7225481e277fb9cbaadc6aa37654a59e0457f8

[gavinp, 2016-05-23 15:02:49]

Description was changed from

==========
SimpleCache: open with fewer seeks.

There's usually no reason to read the file header before reading the
stream 0 (headers) data when opening a simple cache entry. By not doing
so, seeks in the critical path of the loading headers are reduced, which
should speed up http caching performance.

To be careful, the headers are still checked when the first read of data
(if any) is performed. This delays detecting hash collisions in the
cache, because the header data is required to compare keys (instead of
just hashes).

To compensate for the later key comparison, a SHA256 of the key is
stored as an optional prefix to the end of file record. This is used to
validate the key is correct before returning headers to the client.

Because the key checking logic is now totally migrated back into the
SimpleSynchronousEntry, we can return to reporting on key matching in
the SyncOpenResult histograms.

R=juliatuttle@chromium.org,asvitkine@chromium.org,rdsmith@chromium.org
BUG=611732

Review-Url: https://codereview.chromium.org/1977863003
Cr-Commit-Position: refs/heads/master@{#395083}
(cherry picked from commit 9f15f2258d7cae8cd12cb4ef7143ad648a958333)
==========

to

==========
SimpleCache: open with fewer seeks.

There's usually no reason to read the file header before reading the
stream 0 (headers) data when opening a simple cache entry. By not doing
so, seeks in the critical path of the loading headers are reduced, which
should speed up http caching performance.

To be careful, the headers are still checked when the first read of data
(if any) is performed. This delays detecting hash collisions in the
cache, because the header data is required to compare keys (instead of
just hashes).

To compensate for the later key comparison, a SHA256 of the key is
stored as an optional prefix to the end of file record. This is used to
validate the key is correct before returning headers to the client.

Because the key checking logic is now totally migrated back into the
SimpleSynchronousEntry, we can return to reporting on key matching in
the SyncOpenResult histograms.

R=juliatuttle@chromium.org,asvitkine@chromium.org,rdsmith@chromium.org
BUG=611732

Review-Url: https://codereview.chromium.org/1977863003
Cr-Commit-Position: refs/heads/master@{#395083}
(cherry picked from commit 9f15f2258d7cae8cd12cb4ef7143ad648a958333)

Committed:
https://chromium.googlesource.com/chromium/src/+/3b7225481e277fb9cbaadc6aa376...
==========

[gavinp, 2016-05-23 15:02:53]

Committed patchset #1 (id:1) manually as
3b7225481e277fb9cbaadc6aa37654a59e0457f8.