I make apps for other people

Cache eviction

Posted by Chris Jones
On July 25th, 2008 at 17:09

Permalink | Trackback | Links In |

Comments Off on Cache eviction
Posted in Java, Tech

B: size of the buffer
K: number of items having distinct access probabilities

LRU eviction: O(KB)
FIFO eviction: O(K)

Unless it costs a lot more to load an object into the cache, FIFO eviction may make the most sense. In most LRU implementations I’ve written, the cost to maintain the “use” status of the cached object was more expensive than a cache miss because of the object had been evicted. Consider the cost of loading the object versus the SLA for the service. Also, if the cache objects retrieved tend to be clustered very strongly with few if any changes, the cached objects won’t be evicted from the cache very often. A FIFO strategy only loses in the case of a full cache where rarely used objects are occasionally inserted and frequently used objects are evicted and reloaded.

The JVM garbage collector is generally less efficient with larger heap sizes. Heaps over 1 GB with efficient garbage collection is possible if the JVM is properly tuned. Concurrent Mark and Sweep collector may be buggy in very large heaps–tiny JDK 6+ JVMs in federation worked okay. Cache growth should be limited (especially with hashmap caches). The number of long living objects is a problem moreso than the size of those objects, so consider serializing/deserializing the objects to byte arrays (the JVM is optimized around short-lived object garbage collection and the cost of young generation garbage collection is proportionally lower than older generation garbage collection).

Tuning JVM Garbage Collection JDK 5.0

JCS vs Ehcache metrics

Comments are closed.