Expiry after Access / Time to Idle #39
Comments
What status of this implementation? |
|
@quaff Oops, thanks, I changed the title! |
@ricardojlrufino Thanks for reaching out! Its good timing, since I have now stabilized the next version (1.2) and need to do some planing what important stuff to put the focus on next. Two reasons it's not there yet: We rarely need it, there needs to be always a compromise on the performance we have achieved to provide/enable this feature. To drive it in the right direction, I'd love to hear from people who actually need it. Can you share something about the scenario you want to use it for? |
@cruftex My application is from IoT and I cache the Devices in use and, after a while, I need to remove it from memory. |
@cruftex This is a very important feature that I need now. I have more than 100 million elements to cache, but not all of them are accessed continuously (~ 5 millions). The cache eats my ram (> 70Gbs) so I cannot run two instances simultaneously (total 125Gbs). |
@detohaz, @ricardojlrufino: Thanks for your feedback! Unfortunately, I am a bit held up with other activities but there will be some progress here during 2019... For the use cases you describe I still wonder whether TTI is really the best solution. So I like to move in two directions here: Implement TTI but also maybe come up with a better cache feature for 90% of the use cases that use TTI now. @detohaz: You know that around 5 million entries are accessed continuously and should therefore be cached. What about limiting the cache size to 8 million entries and keep the ram usage in check? |
@detohaz: Did my suggestion to limit the cache size help and solve your problem? In case you use a TTI like feature, the actual cache size would depend on the usage pattern. This can lower your heap memory usage, in times when you have low utilization. However, you don't have a guarantee for an upper memory limit. |
Expiry after an entry is accessed. This is (should be) primarily intended for freeing resources if not used, while expiry after modification is an optimization versus business decision (how old is okay?).
For efficiency reasons I intend to do it not 100% on time but with a defined maximum lag.
expiryAfterAccessDuration
Time an entry expires after an access. By default there is lag of 10%, which means the actual expiry might be later then specified. Example: Configured value is 1h, the item may stay in the cache and keep visible for a maximum of 1 hour and 6 minutes after an access.
expiryAfterAccessLag
Configure a different lag time. The minimum lag time is 1 minute.
The text was updated successfully, but these errors were encountered: