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

Joe Cooper wrote:
> Oh, yeah, many will recall Vivek from iMimic pointing out here that
> Squid had a long hit response time at previous events--he and I had a
> little debate about it...It's worth noting the results this time. If
> hit response time is the metric to look at, as Vivek suggests, Squid was
> number four in the pack this time with a very respectable .025 response
> time. I argued for looking at overall response improvement (which leads
> to favoring caches with a higher hit ratio), which Squid did quite
> poorly at this time due to the low hit ratio. As I think Vivek and I
> both agreed, it really comes down to how hard the various components of
> the system are being pushed when deciding what the response time will
> be...and I think Vivek will now agree, that Squid /can/ provide
> excellent hit response times when it isn't being pushed too hard.

I didn't recall stating that any one particular metric was the most
important one, so I checked my postings, and I was unable to find
any suggestion along that line. I'm a big fan of trying to figure out
how the underlying system behaves as opposed to any one particular
instance. The reason for this is because it gives you a better idea
of how things will work out in the future.

First, a little context:

In an earlier post, I mentioned how various boxes were configured
in a non-optimal way at the second cache-off, leading to overall
times that were much worse than they could have been. Not surprisingly,
vendors learned their lesson, and by the third cache-off, there
were lots of entries with better configurations.

Likewise, in the DataComm-1 test, one vendor used a switch that was
as expensive as the cache itself, which caused their price/perf number
to be low. By the time of the next test, they'd switched to a cheaper
switch, and had much better price/perf numbers. If you had looked at
only their original price/perf number without looking at what was
behind it, their huge improvement would have come as a surprise.

Now, for a few comments:

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. That means that the smallest files
don't take up a lot of space, so isolating them onto faster storage
can pay off.

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.

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.

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.

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.

Again, usual disclaimers apply - I work for caching software vendor,
etc., etc.

-Vivek
Received on Thu Dec 20 2001 - 08:38:43 MST