Question on miss and cache size

[peter.waynechina]

"q1. How to know if a GET request was a hit or a miss? q2. For each cluster, what was the cache size when the trace was collected? "

A: when a get request has size 0, we know it is a miss.

The production cache size is not very useful as they are over-provisioned and caches are close to/at compulsory miss ratio.

[peter.waynechina]

Somehow the replies did not get through. 

The production cache size cannot be disclosed and is often much larger than the working set size. 

The WSS field is not correct. We noticed some problems with the table and will update the statistics. 

You are right about zero byte return being a cache miss. 

[Sari Sultan]

Is it safe to assume that the cache size of the recommended clusters is larger than 32GB ? 

[Sari Sultan]

The ones on your GitHub
" Choice of traces for different evaluations

For different evaluation purposes, we recommend the following clusters/workloads

• miss ratio related (admission, eviction): cluster52, cluster17 (low miss ratio), cluster18 (low miss ratio), cluster24, cluster44, cluster45, cluster29.

• write-heavy workloads: cluster12, cluster15, cluster31, cluster37.

• TTL-related: mix of small and large TTLs: cluster 52, cluster22, cluster25, cluster11; small TTLs only: cluster18, cluster19, cluster6, cluster7

"

[peter.waynechina]

The cluster size is way more than 32GB, but the trace is from one instance of the cluster, so we cannot assume the the cache size for the trace is more than 32GB. IIRC, most of them are in the range between 512MB to a few GBs, and cluster52 has the largest cache size (but I do not remember the exact size nor can I share this...)