>1. I think to do disk I/O well is tougher than to
> handle memory hits well.
This is true, but it is not as bad as you think. If total disk throughput is
greater than the total cache throughput, AND the sustainable TPS for
all spindles is greater than the TPS the cache is pushing then there
is pretty much little difference barring memory latency vs disk latency.
>2. If I know a cache can handle disk I/O fast, I know
> it will perform well when the object space is
> huge and diverse.
You will still get that feel anyway. If the cache is logging anything meaningful
you will see what is a memory hit vs a disk hit. This will give you a feel for
how well it is handling disk activity. True, Polygraph can't possibly know what
is a disk or a memory hit, but if everything is skewed away from any semblance
of reality just to determine disk speed, then all you've done is measured how
well the cache will run if everything misses RAM, which is not what happens in
reality. You've measured the worst case scenario, which while a valid measurement,
should not be the "only" measurement.
Our research also shows us that most vendor's caches, when pushed to handle
everything in pure disk mode, generally exhibit the same TPS and latency behaviour
per spindle with minor variations from vendor to vendor (there are some low-end
exceptions). Generally 140-180 TPS per spindle is all that's achievable without
ANY memory read-assist WHATSOEVER (I challenge anyone to prove otherwise)
and this has held across many implementations we have seen. (7200-10000 RPM,
9GB, 5-7ms seek drives).
So basically the vendors are all converging on a common disk performance
level. The physics of moving heads for data reads is the limiting factor here.
Writes can be packaged up as much as one wants and spit out in nice large
chunks, but the reads still require the heads to move at near random distances.
>3. Polygraph uniform model is a very good test on how
> well a cache's disk I/O performs.
See comments above for 2.
Stew.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:10 MDT