Hi,
>OK. So we are probably after 4-6% memory hit ratio for a "typical" 1-2GB
>RAM cache (in Zipf workloads, the memory hit ratio probably follows the log
>law so adding extra GBs gives relatively little after the first few
>percents). We can certainly estimate Zipf parameters based on that
>assumption if vendors do not supply better data.
Why 4-6% memory hit ratio? Where has this figure come from? How does
this relate to real world behaviour? Some vendors have spent a lot of time
explicity studying real world logs and running simulations and tuning algorithms
to handle real-world situations. These correspond directly to improved
memory hit ratios.
I understand the need to prevent the entire working set fitting into RAM, but
lets face it. If vendor X can get 1000TPS say, then at ~13KB/object and a
55% hit rate, we're talking about 5.85MB/sec of new object data flowing into
the system, or 170 seconds per GB. There's no way any working set will
fit into RAM in those circumstances.
Further, our research shows that for 1 week's worth of traffic access at 200TPS,
75% of all cache hits occur within 7 hours of an object being pulled in, and indeed
56% within the first hour. Our research also shows that as TPS increases,
the percentages increase, meaning that each object is more likely to be accessed
more quickly. This correlates directly to higher achievable RAM hit rates.
By artificially restricting everyone to 4-6% memory hits you're stating that vendor X's
approach is invalid if vendor X focussed on improved memory performance.
Stew.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:09 MDT