Closed Bug 924116 Opened 7 years ago Closed 7 years ago

HTTP cache v2: persists frecency and experiment with half-life

Categories

(Core :: Networking: Cache, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla29

People

(Reporter: mayhemer, Assigned: mayhemer)

References

Details

Attachments

(1 file, 2 obsolete files)

Now it's 90 days and it's not persisted.  So we can change it.

I personally propose to lower the decay time to some 24hours only.  The cache will need to throw files after few days of browsing and 90 days is IMO too much.  Entries that are accessed only 2 times 80 days ago will live over entries I've visit now only ones - e.g. a new page I've just discovered.

Other option is to store multiple frecency values with different decays and add telemetry for A|B|C|... testing to find out which value is most effective.  Tho, hard to say what is the quantification of efficiency here...
This is super easy actually - we can store frecency converted back to time (frecency * half-life) and on load covert back with the current half-life that might change between browser sessions.
Blocks: 913808
No longer blocks: 913811
Depends on: 913811
Attached patch v1 (obsolete) — Splinter Review
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Attachment #8349750 - Flags: review?(michal.novotny)
Summary: HTTP cache v2: decide on decay time for cache frecency → HTTP cache v2: experiment with different frecency half-life values
Summary: HTTP cache v2: experiment with different frecency half-life values → HTTP cache v2: persists frecency and experiment with half-life
Duplicate of this bug: 913811
Attachment #8355268 - Flags: review+
No longer depends on: 913811
Comment on attachment 8349750 [details] [diff] [review]
v1

Review of attachment 8349750 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/http/nsHttpChannel.cpp
@@ +93,5 @@
>      else {
>          Telemetry::Accumulate(Telemetry::HTTP_CACHE_DISPOSITION_2_V2, hitOrMiss);
> +
> +        int32_t experiment = CacheObserver::HalfLifeExperiment();
> +        if (experiment > 0 && hitOrMiss == kCacheMissed) {

Why we want to collect only miss statistics?
Attachment #8349750 - Flags: review?(michal.novotny) → review+
(In reply to Michal Novotny (:michal) from comment #5)
> Why we want to collect only miss statistics?

Other possibility is HIT.  HIT = TOTAL - MISS.  We have overall total (when we sum all HTTP_CACHE_DISPOSITION_2_V2 values).  So, I don't see a point.  If you are concerned about evenness of the 4 four test values (what I'm not) then we might also collect TOTAL cache accesses per the experiment value, but I believe those will be even.

What I'm more concerned is how we persist the experiment value in preferences and prevent it's loss because of a crash...  Thinking of a main-thread timer delayed a bit after startup.
https://hg.mozilla.org/mozilla-central/rev/096939370788
Attachment #8349750 - Attachment is obsolete: true
Attachment #8355268 - Attachment is obsolete: true
Attachment #8361656 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
This experiment is still running several years later.  Have there been any conclusions?  Can the experiment code be removed?
Flags: needinfo?(honzab.moz)
(In reply to Matt Brubeck (:mbrubeck) from comment #8)
> This experiment is still running several years later.  Have there been any
> conclusions?  Can the experiment code be removed?

I think yes.  The conclusion is that the half-live has surprisingly no effect on cache hit rate.  Since the cache hit rate is similar to other browsers, I believe there is no need to fiddle with the preference.  Let's remove the code and revert the prefs to something "in the middle".

I'll file a bug.
Thanks.
Flags: needinfo?(honzab.moz)
You need to log in before you can comment on or make changes to this bug.