194619 - Default memory cache size too small

Status: VERIFIED DUPLICATE of bug 105344

(Core :: Networking: Cache, defect)

Description

[Boris Zbarsky [:bzbarsky]]

The default memory cache size seems to be 4mb (see all.js).  Is that correct? 
If so, that's far too small, especially since we have removed the UI to change it.

See bug 93461 comment 62.  Basically, loading a single large (but not
ridiculously so; we're talking digital camera quality) GIF will easily blow out
the entire cache, making image operations in other windows deathly slow.

I believe we should up the default cache size to 20 or 30 mb and make it observe
a memory pressure observer if it does not already....

Note that hyatt's testing showed that a larger memory cache dramatically speeds
up page loads....  I wonder why we never ended up changing the default size.

Comment 1

[Bernard Alleysson]

bug 188458 looks like an alternative

Comment 2

[Boris Zbarsky [:bzbarsky]]

That would help some, but the base issue is that the cache is _tiny_ no matter
what eviction policy we're using.

Comment 3

[tenthumbs]

As long as the pref is hidden I disagree about increasing the size. It
could do a lot of harm on machines with not much RAM. It would also
increase the apparent memory usage which people already complain about.

I also wonder if there isn't something else wrong. I run a squid proxy
and, by default, it uses 8MB for in-transit objects. By default, only
objects <8K are kept in memory. Yet, squid has never been a performance
bottleneck.

Comment 4

[Lorenzo Colitti]

The difference is that Squid only transfers files, whereas Mozilla uses the
cache for other things too. For example, images are stored in the cache in
decoded form, which can be much larger than the files they come from.

Try this: open a window and load about:cache. Then load
http://www.exactaudiocopy.de/ in a new window. Go back to the window with
about:cache and click refresh. Notice that your cache has grown massively. This
is because a 13 KB image on this page takes up more than 6 MB in the cache...

Comment 5

[tenthumbs]

I was fumbling around a little before. On my machine I get the very 
strong impression that running mozilla with my proxy is faster than 
running mozilla alone despite the fact that they're both running on the 
same machine. Obviously this needs to be tested but, if true, suggests 
that the cache is not the issue but, rather, some other networking 
component.

Comment 6

[gordon]

I would suggest this is a duplicate of bug 105344.  Hyatt's original suggestion
was to start at 4Mb for 64Mb machines and ramp up as system RAM increased.  He
proposed 6.25%.  With gigabytes of RAM now, I think something less than linear
growth would be more "friendly".

To address one of tenthumbs concern, we could still have a pref that could
override the dynamic cache size setting.

I'm very interested in those proxy performance results, tenthumbs.

Comment 7

[Darin Fisher]

we've also been talking about allowing a cache session to have a hard limit on
the largest cache entry size allowed (there may be a bug filed for this already,
gordon?).  this could be used to prevent large images from displacing all of the
other content in the cache.  iirc, this is the approach taken by safari (in
conjunction with the LRU-SP eviction policy), and it appears to work very well.
 safari also has a memory cache limit of 4MB, and only steps up its memory cache
size to 8MB when the system has 1GB of RAM.  at least, that's what i've heard.

Comment 8

[gordon]

Limiting maximum cache entry sizes is bug 81640.  It also requests a limit for
minimum cache entry size, but I don't think we need to be a slave to symmetry. 
I don't think a minimum cache entry size would be useful.

Comment 9

[gordon]

Okay, I'm going ahead and marking this a duplicate.

Tenthumbs, when you get more data on the effects of running mozilla with and
without a proxy, please submit another bug and either assign it to me or at
least cc me on it.  Thanks.

*** This bug has been marked as a duplicate of 105344 ***

Comment 10

[benc]

VERIFIED/dupe

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Duplicates shouldn't be marked as blockers; I'll move over to the dupe and make a blocking decision there.