Closed rainjuns closed 1 month ago
1). Yes the traces include "SET" which are triggered due to misses to get operations in our systems. There're some exceptions in KV traces. Notably some clients do "SET" first and then "GET" (after some minutes or hours). These clients are basically prefetching data. They're rare in the traces compared to the regular cache set-after-a-miss workloads.
2). enableLookAside
should only be used when you filter out all the "SET" operations from the original trace. This is useful when you have a cache size drastically different from the cache config, as it will enable CacheBench to behave like an actual cache instead of just replaying the original set traces. (E.g. original hit rate at 90% would have much fewer sets compared to a smaller cache at 50% but receiving the same GET workload).
3). op_count = the number of requests we have seen for this key in this "second" when we collected the traces originally. Each row in our trace represents a second worth of requests per key per operation.
@therealgymmy Thank you for the response. I appreciate it!
Hello, thank you for managing the great project!
I found that cachelib provides several traces in here and I have two questions in testing them using
cachebench
.set
operations caused by misses onget
operations?enableLookAside
) for performingset
operations over misses onget
operations.get
operations beforeset
operations, which can be captured in trace files, is a miss ratio in CacheLib still accurate?get
operations can be captured and they will cause a lot of misses, increasing a miss ratio.enableLookAside
is turned on, manyset
operations will be generated for the same key-value.get
operations for the same key might be queued while waiting the response from the first miss trigger.kvcache/202206
), key:1665497896
will generate a lot of misses:op_count
larger than 1 and (2) multiple trace lines withop_count=1
?