- how often we throw away something that we reload again and after how long - how long it takes until we start throwing stuff away (i.e. fill the pool) - lifetime of an entry in the pool

[ No longer blocks enabling cache2, expected to be fixed after cache2 is on ]

Let's make the list more useful: - time between purge and next load - how often we purge/reload - how many times an entry has been used before it's being purged

So far backing up, I'll go though the patch once more and probably ask for review.

- 3 probes: - time an entry is alive (in the pool, max 2h), - count of usage (equal to frecency update count that is equal to asyncOpen call count), - time between purge and subsequent reload of the same entry again, 15 minutes max - service keeps a hashtable to track the reload time (urls could be large, maybe we should somehow compress them?) - registration and deregistration are used to track addition and removal of entries, this way it's ensured that a new same-URL entry cannot be first added and the previous one only after that removed

Comment on attachment 8449685 [details] [diff] [review] v1 Review of attachment 8449685 [details] [diff] [review]: ----------------------------------------------------------------- ::: netwerk/cache2/CacheStorageService.cpp @@ +1795,5 @@ > + if (!TelemetryEntryKey(entry, key)) > + return; > + > + TimeStamp now = TimeStamp::NowLoRes(); > + mPurgeTimeStamps.Enumerate(PrunePurgeTimeStamps, &now); I think we should somehow limit the call to PrunePurgeTimeStamps. It isn't necessary to do it every time we register/unregister an entry.

Good catch. Pruning limited to happen just once in a minute.