-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support simulations of large caches in weighted policy types
In weight-based traces the entries have different sizes, e.g. bytes. The policies that support this characteristic will evict multiple entries until at its maximum-size contraint. This was an integer setting which is too small for the Tencent Photo trace. The setting was increased to a long and the weighted traces updated accordingly. The other traces use a checked cast to an int value as a minimal migration to minimize the chance of introducing bugs. The linked policy was fixed to handle the entry's weight changing on a cache hit. The AdaptSize simulator compatibility was reduced to only its trace reader. That simulator treats the same key with different weights as distinct entries, rather than an update. The workaround of hashing the key and weight as the entry's key causes noticable workload skew. Since other simulators (like LHD from the same group) don't make this odd choice, its now restricted to just their trace reader.
- Loading branch information
Showing
53 changed files
with
178 additions
and
121 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,10 +25,14 @@ | |
import com.github.benmanes.caffeine.cache.simulator.policy.AccessEvent; | ||
import com.github.benmanes.caffeine.cache.simulator.policy.Policy.Characteristic; | ||
import com.google.common.collect.Sets; | ||
import com.google.common.hash.Hashing; | ||
|
||
/** | ||
* A reader for the trace files provided by the authors of the AdaptSize algorithm. See | ||
* <a href="https://github.com/dasebe/webcachesim#how-to-get-traces">traces</a>. | ||
* <p> | ||
* The AdaptSize simulator treats identical keys with different weights as unique entries, rather | ||
* than as an update to that entry's size. This behavior is emulated by a key hash. | ||
* | ||
* @author [email protected] (Ben Manes) | ||
*/ | ||
|
@@ -47,7 +51,12 @@ public Set<Characteristic> characteristics() { | |
public Stream<AccessEvent> events() throws IOException { | ||
return lines() | ||
.map(line -> line.split(" ", 3)) | ||
.map(array -> AccessEvent.forKeyAndWeight( | ||
Long.parseLong(array[1]), Integer.parseInt(array[2]))); | ||
.map(array -> { | ||
long key = Long.parseLong(array[1]); | ||
int weight = Integer.parseInt(array[2]); | ||
long hashKey = Hashing.murmur3_128().newHasher() | ||
.putLong(key).putInt(weight).hash().asLong(); | ||
return AccessEvent.forKeyAndWeight(hashKey, weight); | ||
}); | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
ecd5e13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the large caches compatibility.
I'm not sure it's such an odd choice to rehash the
key
with theweight
. I find it very reasonable.If one asks for an item with a different
weight
it is other item, even if it has the samekey
. Perhaps there was a write in between, but since the simulator does not handle writes, I think we could not consider it as a hit that we can serve from the cache (as we do now).ecd5e13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it should be a flag then? It certainly doesn't seem consistent across simulators and I agree it's awkward either way. I'd be fine with whatever changes you want here.
ecd5e13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A flag seems like a good solution.
BTW, the
TencentPhoto
trace has a lot of such entries (~5 out of ~20 million that I checked). It makes a big difference to the measured hit-ratio (even forLRU
with different simulators).ecd5e13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. I suppose the alternative is that every weighted policy should validate and replace? That might be a better option since the flag will be weird either way (e.g. why hold onto the old entry with the different weight?) and simulate it as a cache miss?
ecd5e13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, maybe it should. My current workaround is to rewrite the trace with the new hashing but evicting the old key could improve the performance.
ecd5e13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, either open an issue and I'll try to get to it, or send a PR 😄