-
Notifications
You must be signed in to change notification settings - Fork 175
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
Cache expiration recommendations #33
Comments
There is much simpler approach - to maintain two caches and swap them periodically while resetting the oldest one. This approach is used by VictoriaMetrics - see https://github.com/VictoriaMetrics/VictoriaMetrics/blob/7d73623c6989a27a297358453a963d75c4ceedc1/lib/workingsetcache/cache.go |
@valyala Thanks for sharing! However, looking at the code and comments it seems that the solution doesn't fit the described use case.
If my understanding is correct, this refers only to |
I pretty much went for However, I think it would be nice to have a way to iterate over cached keys. This would enable various flows, but not sure how this fits on Thanks! |
@bogdanciuca , there is a pull request for this - see #3 |
I see it has not been merged because of performance issues and you previously recommended forking. Is there no other solution to have this functionality in |
There were no clear needs for visiting all the cache entries since the #3 has been proposed, so it is unlikely it will be merged soon. Could you share practical use cases for this solution? Probably there are better solutions for some of them. |
I'll revisit our use cases and share some more details. |
@valyala So I ended up dropping So now I have a So I guess my point here is that I could've used just |
While I completely agree with this statement, this only handles "cache hit" expiration. How would you recommend implementing a scheduler, that cleans up the cache once in a while?
The main issue is that I don't see a way to "iterate over all cache keys", neither a way to "delete all by value" (e.g. by expiration) in order to implement this.
Currently, it seems that the only possible way to achieve this is by creating an additional data structure (e.g. thread-safe
map[string]int
withtokenKey -> expirationVal
or reversed,map[int][]string
withexpirationKey -> []tokenVal
) in order to have some sort of iteration over keys / expirations.However, this adds extra complexity (has to be kept in sync, so basically holding a cache for another cache) and memory (duplicating the keys), especially in cases with large keys (I'm using ~1000 char JWTs as keys, no need for value in this scenario, just expiration, which is usually quite big, e.g up to 24 hours).
@valyala Looking forward to hear you take on this, I would really like to use
fastcache
in our products.The text was updated successfully, but these errors were encountered: