-
Notifications
You must be signed in to change notification settings - Fork 5
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
Ristretto #19
Comments
I've never used ristretto in production, tho I am a minor contributor 😉 One clear issue with the LRU driver is the size specification on number of entries rather than total memory usage. It's much more convenient to specify cache size in memory consumption so... assuming it works as advertised... I'd be open to using it. However, if it's added as a native driver to this package, it would become a dependency. Do you think it's good enough to replace driver_lru and driver_arc? |
To reiterate, I consider Memory Bounding a first class problem, even to the extent that I would consider significant (non-backward compatible) interface changes if those changes enabled cache size specification in bytes rather than number of entries. |
I tried to create a Ristretto driver: erikdubbelboer@fcc4f14 I haven't tried to use it or test it yet! Adding it to the current tests doesn't work as Ristretto behaves quite differently from the current caches. The main issue I was having is that the And I just realize this implementation doesn't work at all :( Microcache uses a separate hash key for the @kevburnsjr have you ever thought about what happens when a |
The relationship between RequestOpts and Response is one to many. When a request varies by (say) When RequestOpts is evicted, the request will go to origin. I don't think it's problematic for the two caches to evict independently. It just requires that the constructor create and maintain one cache instance for each. |
I'm planning to do a test of https://github.com/kevburnsjr/microcache/compare/master...erikdubbelboer:ristretto?expand=1 next week. I'm currently traveling so I hadn't gotten around to it yet. |
So far results have been bad, ristretto seems to have a bug where it leaks memory: dgraph-io/ristretto#96 |
Interesting. I ran your proof with two different versions of ristretto and got 2 different results.
Sep 28th 8acd55ed71b051ac104a2b67f090d82596f8d259
|
Here's the offending commit
|
Found the bug and submitted a PR. |
🚦 Green light |
This has been running very stable in production for some weeks now. Should I make a pull request to add this adapter? |
Lacking only a PR to update examples & readme |
I was just wondering if you looked into using https://github.com/dgraph-io/ristretto instead of https://github.com/hashicorp/golang-lru. Its similar but seems a bit better suited for a cache like this. See: https://blog.dgraph.io/post/introducing-ristretto-high-perf-go-cache/
I thought I'd ask before I write a
Driver
for this to test it.The text was updated successfully, but these errors were encountered: