Cache Flashcards
remember: network calls are…
blocking
primary use case for caching
you find yourself frequently accessing the same data from a remote server.
define a cache ‘miss’
miss-rate
data is requested from cache, and it doesn’t have it
miss-rate: the percentage of requests that were misses
define a cache ‘hit’
hit-rate
data is requested from cache, and it has the data
hit-rate: the percentage of requests that were hits
in Guava cache framework, the 3 core classes
LoadingCache
CacheBuilder
CacheLoader
Loading Cache (Guava framework)
This class manages a cache, keeping objects in a Map and automatically retrieving new data from the data store on a cache miss
CacheBuilder (Guava framework)
This factory class creates properly configured instances of LoadingCache
CacheLoader (Guava framework)
LoadingCache uses a CacheLoader that we configure to retrieve new data from the data store.
high miss-rates indicate that…
…many requests make the expensive request AND add overhead to check and update the cache.
Cache is most helpful when…
… the system requests the same information repeatedly. You benefit from the cache only if you request the same data again and resuse the previous result.
Programs with high miss-rates may improve the cache performance by…
…adjusting the cache configuration size
adjusting the cache TTL
evaluating if users reuse the same data
“sweet spot”
amount of RAM that Guava defaults to use
Guava defaults to using all available RAM. Devs always set an upper limit on the amount of memory the cache can use, via the CacheBuilder’s method maximumSize()
maximumSize()
method in Guava’s CacheBuilder that sets the maximum amount of memory the cache will consume, in number of entries (of the pair)
where is maximumSize() set?
this is set in your CustomizedCacheDao constructor:
public CustomCacheDao(DataAccessDao accessDao)
loadingCacheVariable = CacheBuilder.newBuilder()
.maximumSize(50)
.build(CacheLoader.from(accessDao::getData)
);
how does Cache evict data?
When the cache already contains the maximum number of entries, and we request a new key, the cache evicts the least recently used entry to make space.
staleness
Data that is out of date and no longer valid. The data has changed on the remote source, and is different from what we have in our cache.
cache invalidation
difficult process of trying to remove stale data
Guava’s expire based on time methods
in CacheBuilder:
.expireAfterAccess(6, TimeUnit.HOURS)
or
.expireAfterWrite(6, TimeUnit.HOURS)
Guava’s expire based on time methods
in CacheBuilder:
.expireAfterAccess(6, TimeUnit.HOURS)
or
.expireAfterWrite(6, TimeUnit.HOURS)
used when instantiating the cache, just like .maximumSize() and .build(CacheLoader.from(accessDao::getData)
When a cache entry is expired…
…Guava will re-load the information from the remote data store even on a cache hit.
expired data term
In caching terminology, the maximum “age” is called Time To Live (TTL), as in “ the item will live in the cache for this amount of time”
TTL
depends of your application’s need for fresh data. A tradeoff between hit-rate and staleness
.expireAfterAccess(num, TimeUnit.unit)
specifies the amount of time (num) that can elapse after the last time an item in the cache has been accessed before it is invalidated.
“access” refers to writing to the cache and reading from the cache.
As long as the callers request the item more often that that TTL, it won’t be invalidated.
(for num=6, if the cached item hasn’t been used in 6 hours it will be invalidated)
example: frequent items in cart
.expireAfterWrite(num, TimeUnit.unit)
invalidates an item in the cache a specified amount of time after it was written to the cache ragardless of how recently it was read.
example: movie recommendations (want to forward recent trends to the customer)
Data that remains relatively static
product description
addresses
informational type of records
–>longer TTL
Data that remains relatively static
product description
addresses
informational type of records
–>longer TTL
if data has a low chance of becoming stale, or has a minimal impact when stale
–>use .expireAfterAccess with a long duration
Data that has a high liklihood of change
product ratings
prices
popular products
–>lower TTL
for data that changes frequently, or which is more sensitive to staleness
–>use .expireAfterWrite with shorter duration
If data has the potential to have a negative impact when it becomes stale, or that it might become stale more often…
…use .expireAfterWrite
We shouldn’t make the problem worse by continuing to extend its life each time someone requests it (.expireAfterAccess)
