> The Swell entry did a lot better on hit time than previous cacheoffs,
> and I'm guessing that the underlying cause was largely the RAM disk.
> It makes sense, since this workload has a median file size that is
> smaller than its mean file size.
...which, of course, is true in spades for real cache workloads.
Your point?
> b) Is this approach scalable? The three entries with better hit times
> had throughputs roughly 4-20 times as high. So, if your system can
> only hold 4GB of memory, the RAM disk approach has less than a
> factor of 2 from its current numbers before one would expect some
> degradation.
That's a silly comparison. You configure a given system to do best
with the load it's given. One would almost think you were bringing
this up to highlight iMimic's better throughput :-). Permit me to
remind you of Squid's superior latency improvement/$ :-).
> c) Is the comparison fair? Since polygraph/polymix is a disk-bound
workload . . .
Of course it's fair. He had to pay the cost of the RAM in his entry.
> d) Finally, there's the issue of whether stable storage is important
> for a proxy or not. If a large fraction of the content is stored on
> a RAM disk, a reboot or power loss is a significant concern. My
> conclusion is that if you can do without the RAM disk, it's
> probably better to build a cache that uses stable storage for files
> and uses memory only as a hot object cache.
It's a CACHE. When the power goes out, your hit rate suffers for
awhile and then you come back. If your cache is located in
Afghanistan, then I recommend going with the stable storage.
-- Jon Kay pushcache.com jkay@pushcache.com http://www.pushcache.com/ (512) 420-9025 Squid consulting 'push done right.'Received on Thu Dec 20 2001 - 12:27:50 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:26 MST