Re: [squid-users] fourth cache off??

On Thu, Dec 20, 2001, Vivek Sadananda Pai wrote:

> The real questions then are what are the tradeoffs. I see the
> following:
>
> a) Is that memory better used as a RAM disk or just as more memory for
> the proxy itself? Three entries had better hit times than the Swell
> entry. Those entries had 512MB, 1GB, and 2GB of memory, and the Swell
> box had 2GB. Those three entries were also running at much higher
> request rates, so it's not clear that all proxy designs need as
> much memory, regardless of whether it's used directly by the
> proxy or as a RAM disk.

Thats just an implementation issue. You should be asking "is it worth
using a multi-layer storage system, a general buffer cache, a hot
object cache, or some hybrid?"

> 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.

Oh, I'm sure with the RAM disk _and_ improvements in squid's internal
code the throughput could go through the roof too. :-)

> c) Is the comparison fair? Since polygraph/polymix is a disk-bound
> workload, hit response time often depends on the amount of stress
> on the disk. Here, I would look at hits/disk as a good metric to
> see how hard things are being driven. Since that's not easily
> available, it's useful to look at the reqs/disk instead. That's at
> http://www.measurement-factory.com/results/public/cacheoff/N04/auto/all/tput_per_disk.html
> The three entries with better hit time had req/disk values of
> about 350, 500, and 625. Swell's entry was around 65 req/disk.

Thats just a UFS issue. If I had the time and managed to get COSS
stable enough for this cacheoff, the req/disk would have been much
higher. :-)

> 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.

Read a) - if one uses a tailored system the performance tradeoff
may actually be worth the small loss in object data at startup.
(If you have a set of objects that are so frequently accesed
that they stay in RAM disk and never "bubble" out to disk for
some reason or other, if you restart your cache you're still
going to (statistically) fetch them quickly.. bit of bandwidth
waste but..)

Adrian
Received on Thu Dec 20 2001 - 16:00:45 MST