Results of cache usage study

[Nick Hurley]

All, I've posted the results of my cache usage survey to
http://todesschaf.org/posts/2012/07/25/cache-usage-results.html

The short version of the story is that it appears we can
*significantly* reduce the max size of the disk cache without causing
problems related to unnecessary churn in the cache. I propose we do
the following:

(1) Cut the default max size from 1GiB to 512MiB for Firefox 17. Watch
telemetry for hit rate to make sure there are no unexpected bad
effects. Also, watch telemetry for lock wait time to see if this helps
at all with that (in parallel with other lock contention reducing
work). Assuming no objections here and a quick r+, a patch for this
could be landed tomorrow.
(2) When development starts on Firefox 18, cut the default max size
further to 350MiB (similar to chrome's number). Again, watch relevant
telemetry for any contraindications.

Why the 2-phase approach? To help mitigate the (once per version)
effect of slowing down startup by evicting a bunch of entries. It also
gives us a longer window to keep an eye on things, and having multiple
steps can help us see if the win by dropping to 350MiB is really more
significant from dropping to 512MiB (this of course assumes we see a
significant win from either of these actions).

Anyone have any concerns, or should we go ahead and give this a shot?

[Jason Duell]

It's great to have this data--thanks Nick!

I'd measure how long it takes to evict 500MB--I assume it'd happen at
startup, and possibly be quite noticeable to browser perf. If so it
might actually be better to just blow away the cache (which is lots of
I/O but we've gotten to a point where it doesn't block the browser
otherwise) and instantiate the new limit for the new cache. We could
also jump right to 350 MB.

Bug 709297 could be the right place for this.

Cheers,

Jason

[Nick Hurley]

Yeah, the initial startup hit is the one thing that worries me about
deleting so much data at once. What we could do is make eviction
async, which would allow us to cut the cache to any size we want
without worrying about hanging the UI. That would, of course, make the
patch take a little longer to write, but it would kill two birds with
one stone (fixing the sizing issue, as well as making yet another of
the cache APIs asynchronous).

Bug 709297 definitely looks like a good candidate for this work.

> _______________________________________________
> dev-tech-network mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-network

[Jason Duell]

It's sort of sad, but another fix that could work here would be to
record the new cache limit but not enforce it until the next time the
cache get blown away for a crash or other unclean close. That seems to
be happening often enough that it's a viable migration strategy...

Jason

[Patrick McManus]

On 7/26/2012 11:29 PM, Jason Duell wrote:
> It's sort of sad, but another fix that could work here would be to
> record the new cache limit but not enforce it until the next time the
> cache get blown away for a crash or other unclean close. That seems
> to be happening often enough that it's a viable migration strategy...

That's clever! +1

[Nick Hurley]

OK, sounds like a plan. We might also be able to use this plan to see
if the 10% unclean startup number is limited to a small number of
(very) unlucky users, or if it's spread more easily across the
population. I'll go ahead and assign 709297 to myself for the patch.