-
-
Notifications
You must be signed in to change notification settings - Fork 75
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
Adaptive cache eviction #101
Comments
Caffeine has released with the latest adaptive algorithm. Do you know how it compares to Cache2k now? |
@hc-codersatlas: You can run the benchmarks with traces as explained in https://cruftex.net/2016/05/09/Java-Caching-Benchmarks-2016-Part-2.html Be aware that this is rather academic and any result may or may not apply to your actual workload. I will take a deeper look on this later in time. The goal of cache2k is to have good enough eviction results with very low overhead in the critical access path. That said, the goal is not having better eviction results then any other cache. In that sense, I see cache2k well balanced out. |
The last days I've been working quite a bit on the eviction. For the tests of the adaption algorithm of Caffeine Ben was using a trace that leads to quite devastating hitrates in cache2k. I improved the testbed for eviction algorithms in
The trace One reason for the outcome is, that the current eviction algorithm is keeping not more referenced hot entries too long. The removal of the demotion from hot to cold space from the original Clock-Pro algorithm shows good results. It seams that in combination with the hit counter this is not necessary, I plan to release what I have now, which looks like a good improvement increment as in upcoming version 1.4. Here is the comparison:
On bigger and realistic workloads it looks like this:
Except for corda at the small cache size of 512 entries, the to be released cache2k v1.4 is within a range of -3,5 and +2,5 hitrate difference compared to Caffeine 2.8. The static tuning, which comes with cache2k currently, favors more skewed distributions that will be found in typical web traffic, but it is less favorable for transaction oriented workloads. |
fyi - I cannot reproduce the |
I double checked. I missed to take over a tiny change from the testbed version to production. I will do a new release tomorrow. My bad. Release early, release often.... Thanks @ben-manes ! |
V2.6 gets a tiny chance because I discovered a not optimal behavior. The current eviction algorithm (V1.x - V2.4) inserts entries evicted from hot into the ghost history. However, that makes no sense, because the entry will hardly have better reuse distance next time. The original Clock-Pro algorithm is also not doing this. Here is the result when compared to V2.4.1.Final:
All real world traces benefit, while artificial traces (Zipfian and loop) do loose a bit. So this modification will be included in V2.6. |
Corrected statistics with the V2.6 change without changing hot max:
The effect is actual minimal, however, it has relevant savings in processing time, so I keep it. |
The cache2k clock-pro algorithm runs with fixed sizes of data structures that yielded the best results over all benchmark trace I could get a hold on, see: https://cruftex.net/2016/05/09/Java-Caching-Benchmarks-2016-Part-2.html
Nevertheless there are some patterns that result in worse hit rates than LRU.
Ben is experimenting with some adaptions, that look interesting. See: ben-manes/caffeine#106
The text was updated successfully, but these errors were encountered: