Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expiry after Access / Time to Idle #39

Open
cruftex opened this issue Feb 17, 2016 · 8 comments
Open

Expiry after Access / Time to Idle #39

cruftex opened this issue Feb 17, 2016 · 8 comments
Assignees
Labels
Milestone

Comments

@cruftex
Copy link
Member

@cruftex cruftex commented Feb 17, 2016

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.

@cruftex cruftex added the feature label Feb 17, 2016
@cruftex cruftex added this to the v1 milestone Feb 17, 2016
@cruftex cruftex mentioned this issue Feb 17, 2016
@cruftex cruftex changed the title Expiry after Access Expiry after Access / Time to Ilde Mar 29, 2016
@cruftex cruftex modified the milestones: v1.2, v1 May 18, 2016
@cruftex cruftex removed this from the v1.2 milestone Jul 3, 2018
@ricardojlrufino
Copy link

@ricardojlrufino ricardojlrufino commented Aug 16, 2018

What status of this implementation?
The main feature I needed was this ...

@quaff
Copy link

@quaff quaff commented Aug 17, 2018

Ilde in title should be idle

@cruftex cruftex changed the title Expiry after Access / Time to Ilde Expiry after Access / Time to Idle Aug 17, 2018
@cruftex
Copy link
Member Author

@cruftex cruftex commented Aug 17, 2018

@quaff Oops, thanks, I changed the title!

@cruftex
Copy link
Member Author

@cruftex cruftex commented Aug 17, 2018

@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?

@ricardojlrufino
Copy link

@ricardojlrufino ricardojlrufino commented Aug 19, 2018

@cruftex My application is from IoT and I cache the Devices in use and, after a while, I need to remove it from memory.
I ended up using the Guava library, unfortunately it is very large (2MB), and I only use it for cache.

Ref: https://github.com/google/guava/wiki/CachesExplained

@detohaz
Copy link

@detohaz detohaz commented Jun 3, 2019

@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).
I have divided into smaller partitions (32 partitions) to improve access time, and now I'm dealing with memory problems.
Hope that this feature will be implemented as soon as possible.
Thank @cruftex.

@cruftex
Copy link
Member Author

@cruftex cruftex commented Jun 3, 2019

@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?

@cruftex
Copy link
Member Author

@cruftex cruftex commented Sep 9, 2019

@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.

@cruftex cruftex added this to the v2 milestone Sep 9, 2019
@cruftex cruftex self-assigned this Sep 9, 2019
@cruftex cruftex modified the milestones: v2, v2.x Oct 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants