• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • alexsnaps
  • Reporter: elygre
  • October 22, 2009
  • 2
  • Watchers: 3
  • July 27, 2012
  • September 07, 2011

Description

I’d like to be able to configure the in-memory cache size in terms of an absolute memory footprint.

An issue that I have encountered in many cache implementations, including ehcache, is that it’s not always possible to accurately estimate the average size of an cached element.

For example:

If I want to cache elements of User-Generated-Content, there will be some days when the average content size is 4KB, and other days when the average is 200KB.

If I know that I have 400MB of RAM on my server available for caching, but to avoid the risk of running out of memory, I have to choose a cache size of 2048 elements, to cater the for larger content (2048 x 200KB = 400KB).

On a “small content” day, I would then end up only using 8MB of the 400MB of RAM that I have available.

What I’d really like to do is configure the cache as 400MB, rather than having to state the number of elements.

Sourceforge Ticket ID: 2644189 - Opened By: chbb77 - 27 Feb 2009 04:44 UTC

Comments

Eirik Lygre 2009-10-22

(I cloned this issue, but probably shouldn’t have – I expected to be able to create a new description, which obviously isn’t the case.)

We’re in the process of starting to use Ehcache as a content cache, much as in the description above. Since we don’t know the size distribution of the content (we have *no* idea!), and since the size distribution could change over the execution lifetime of the application, we are hard pressed to come up with reasonable values for cache size.

What would be desired semantics for us is that provided by java.lang.ref.SoftReference:

“Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches. … All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. Otherwise no constraints are placed upon the time at which a soft reference will be cleared or the order in which a set of such references to different objects will be cleared. Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references.”

Our use case, then, has the following properties: * We *can* recreate the cache content at any point in time * We don’t really *want to* recreate content, since that is an expensive operation…which is why we cahce in the first place :-) * We want the cache infrastructure to handle all of this for us

Alex Miller 2009-10-26

We’re actually looking at some features that would allow you to specify your max cache size in terms of memory usage. If we had that (say ProductCache max size = 200 MB) would that make you happy from a usage perspective?

Ehcache-terracotta actually already has something similar to SoftReferences in that cache entries will be flushed out of the JVM and faulted back as needed (without forcing you to recreate the content).

Eirik Lygre 2009-10-26

Setting a max cache size in terms of memory usage would absolutely make me happy. I somehow thought that calculating the object size would be difficult or expensive, but I guess that’s my fault for not thinking in terms of root requirements :-)

Fiona OShea 2010-03-11

Updating Target = Darwin to Terracotta Target = Darwin

Fiona OShea 2011-04-20

Scheduled for the next major Ehcache release

Alexander Snaps 2011-07-13

Ehcache 2.5 beta1 was just released, it has that feature built in. More info here : http://www.ehcache.org/documentation/configuration.html#Memory_Based_Cache_Sizing_Ehcache_2.5_and_higher