Increase Fennec's disk cache size

RESOLVED FIXED in mozilla14

Status

()

Core
Networking: Cache
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: blassey, Assigned: gbrown)

Tracking

unspecified
mozilla14
x86
Android
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(blocking-fennec1.0 beta+)

Details

Attachments

(1 attachment)

We currently use a smaller disk cache than other browsers, and I suspect that may be hurting us.
Some data on existing cache sizes:
http://www.stevesouders.com/blog/2012/03/22/cache-them-if-you-can/
(search for 'Galaxy Nexus: 18 MB')

and:
http://www.stevesouders.com/blog/2010/07/12/mobile-cache-file-sizes/
(Reporter)

Updated

5 years ago
Assignee: nobody → gbrown
blocking-fennec1.0: ? → beta+
Geoff, do you have a strategy for picking an appropriate size here?
(Assignee)

Comment 3

5 years ago
I think there is tension between cache effectiveness (cache it if you can / maximize cache size) and user tolerance for loss of usable storage ("firefox is a disk hog -- it's using 50% of my available storage!" / minimize use of storage).

As a starting point, I would like us to be comparable to other mobile browsers, so I am testing several browsers on several devices to get a better idea of cache sizes for other browsers.
(Assignee)

Comment 4

5 years ago
Oh darn, it's complicated!

Max cache size of the stock browser varies across devices. I monitored the size of the stock browser cache directory on various devices while browsing and noted the approximate maximum size on each:

Nexus 1 - Android 2.2 -         6 MB
Galaxy S - Android 2.2.1 -      6 MB
Galaxy Nexus - Android 4.0.3 - 24 MB
Galaxy Tab - Android 3.1 -     35 MB

The Dolphin browser appears similar: 10 MB on Galaxy S and 30 MB on Galaxy Tab.

We should also keep in mind that other browsers typically use the Android cache directory while Fennec does not - bug 742558.


Storage space varies widely across devices: Newer devices and tablets especially have much more space - and tolerance for storage-intense apps - than older phones. Perhaps the smart-sizing feature could be expanded to accommodate mobile? That might be the best long-term solution.

In the short-term, 10 MB seems pretty reasonable, but perhaps we could make it 20 MB: see how that affects telemetry hit rates, and if it generates any complaints.
We could probably check for the amount of RAM on the device and adjust accordingly.
(In reply to Mark Finkle (:mfinkle) from comment #5)
> We could probably check for the amount of RAM on the device and adjust
> accordingly.

Which is what you suggested in comment 4. I'd rather err on the larger size to start with as well.
(Assignee)

Comment 7

5 years ago
Created attachment 614918 [details] [diff] [review]
increase max disk cache size to 20MB

I reported bug 745340 to encourage a better solution, but anticipate that may take a while to sort out. Meanwhile, let's bump to 20 MB.
Attachment #614918 - Flags: review?(mark.finkle)
Comment on attachment 614918 [details] [diff] [review]
increase max disk cache size to 20MB

Let's see what data we get. Reverting is easy.
Attachment #614918 - Flags: review?(mark.finkle) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/6f44748aa046
Flags: in-testsuite-
Keywords: checkin-needed
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/6f44748aa046
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
taras,

I awhile ago we enabled disk cache to collect telemetry.  I understand that the disk cache caused startup and some jank woes.  Do you still have that data?

Reopening to sort out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
closing the bug again, the patch has been pushed and this has been resolved
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Comment 13

5 years ago
Our cache has some massive problems...including janking the main thread, blowing itself away on uncleanshutdown, etc. 
I thought we disabled disk cache because it provided more pain than gain...what changed?

Comment 14

5 years ago
I can't find any bug#s to do with disabling the cache, but here is an email I wrote to relevant people:

NETWORK_DISK_CACHE_OPEN is almost never 0(unlike on desktop), indicating that we are doing something expensive there.  A large number of those are 100-3000ms. No other startupy histogram metrics are similarly slow.

On the non-startup side:
Various histograms that measure time to fetch entry from disk are also on the expensive side(ie HTTP_PAGE_CACHE_READ_TIME).
HTTP_OPEN_TO_FIRST_FROM_CACHE is not obviously better than HTTP_OPEN_TO_FIRST_FROM_RECEIVED...infact the median time is worse.

Note it seems like the recent landing of bug 648429 has shifted HTTP_OPEN_TO_FIRST_FROM_CACHE to the left(ie less time spent reading). This effect is quite obvious on fennec, not so obvious in desktop firefox.
I think it was our mistake not disabling the disk cache on m-c after we collected this data.  We should disable the disk cache given this data you collected.
(Assignee)

Comment 16

5 years ago
Bug 645848 enabled disk cache for fennec. 

Bug 717031 disabled it on aurora only, for FF11, citing 3 bugs: 707436, 713480 and 716293. 707436 and 716293 are resolved/fixed; 713480 applies only to a disabled feature.

NETWORK_DISK_CACHE_OPEN has not improved much, but HTTP_PAGE_OPEN_TO_FIRST_FROM_CACHE is now substantially better than HTTP_PAGE_OPEN_TO_FIRST_RECEIVED (for 13.0, median of approx 100ms vs approx 700 ms.)

Comment 17

5 years ago
I can't argue about this because the telemetry dashboard is not reporting population samples atm :( bug 747192

Comment 18

5 years ago
Should we re-open this bug until bug 747192 is resolved?
Hey jp,

We spent a few weeks (a few years ago) looking for a major perf regression that turned out to be the disk cache. I think we need *overwhelming* data that suggests that enabing the disk cache is a good idea.  Right now, we do not have that.  If we do, please point me at it.

The disk cache is a major feature that hasn't proved itself yet.  This late in the game, it is best to cut it.  There will be future releases in which we can completely verify that enabling this feature is a good idea.

I will let you and brad sort out which bugs to open or reopen.
You need to log in before you can comment on or make changes to this bug.