You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the only eviction strategy is one of absolute time. If there was a method to define a "size" of cache, it would be worth exploring a "Least Recently Used" system to ensure that the hottest items stay in the cache.
Thoughts:
Implement an extension (eg. AutoEvict/FixedCapacity) that manages the more advanced eviction strategy
New extension tracks number of items in the cache, cache keys, expiry dates and last access dates
Could use a LinkedList to track most recently used or a timestamp directly
Probably easier with a ConcurrentDictionary with cache keys as the key and a custom type as the value
Once a criteria has been hit (eg. X number of items in the cache), use what it knows to evict locally
Challenges:
Keeping the extension up-to-date with cache data
Can use the various extension hooks but still is a bit fiddly
Only evicting locally
Can do what I already do for RedisRemoteEvictionExtension (pass the cache layers in directly) but it is pretty cumbersome
Notes:
To handle a distributed LRU would be excessively complex and likely not useful. Would mean that every access to a cache item (including local) would have to then broadcast that access back through the cache system and whatever distributed backends are used.
The text was updated successfully, but these errors were encountered:
Not sure how applicable it is to this given its a LFU not an LRU plus it is a storage mechanism, not an eviction strategy. There still might be some useful pieces of information to extract from it.
Issue created from #53 (comment)
Currently the only eviction strategy is one of absolute time. If there was a method to define a "size" of cache, it would be worth exploring a "Least Recently Used" system to ensure that the hottest items stay in the cache.
Thoughts:
AutoEvict
/FixedCapacity
) that manages the more advanced eviction strategyConcurrentDictionary
with cache keys as the key and a custom type as the valueChallenges:
RedisRemoteEvictionExtension
(pass the cache layers in directly) but it is pretty cumbersomeNotes:
To handle a distributed LRU would be excessively complex and likely not useful. Would mean that every access to a cache item (including local) would have to then broadcast that access back through the cache system and whatever distributed backends are used.
The text was updated successfully, but these errors were encountered: