Re: [squid-users] Ideal cache placement (was Re: Why Squid is great (was: fourth cache off??))

From: Vivek Sadananda Pai <vivek@dont-contact.us>
Date: Sun, 23 Dec 2001 09:36:05 -0500

Jon Kay wrote:
> That said, there is a legitimate point that I was getting at
> concerning cache hierarchies. You guys spent time implementing ICP.
> Why is that, if you feel coordinated caching is a bust?

Again, you're misrepresenting what I said. I questioned the
logic of throwing around lots of small caches without having
choke points that required them. I stated that I believe
that having caches at chokepoints makes sense. Nowhere did I
state that there is no place for coordinated caching of any kind.

> > > There you go. Your users are 1/8 faster if you go Hint Cache. And
> > > it's all far more scalable.
> > As for your strawman comparison, it would be a lot more believable
> > if the numbers were from an actual large deployment,
>
> On the contrary, that's what benchmarks are for. Just which point
> during the day should one take deployment numbers for? How typical is
> that deployment? Is it atall comparable to this Squid (or pushcache)
> deployment?

The polymix numbers are derived from real traces. If you want to
make claims about what sort of performance you'd get from hint
caches, it would be a lot more interesting if there were large
deployments that could be independently observed and then used
for building a believable benchmark.

> > or if you'd
> > used the best DataReactor numbers (17ms hit, 2652ms miss).
>
> I used the numbers from your own box! Are you disowning them?!?

The DataReactor software runs on a number platforms under a
wide variety of configurations. If you want to compare it with
the best Squid numbers ever produced, you should at least be
fair and use the best DataReactor numbers ever produced. It's
also worth noting that our OEMs actually ship those configurations,
whereas in the past, some of the Squid numbers have been for
unstable configurations that would never have been placed in
production - just benchmarketing.

> Plus, the iMimic throughput numbers are slightly less than 10x the
> Swell/Squid numbers, which, since I was talking about 10 Squids vs. 1
> iMimic, happens to model the relative load factors nicely.

The highest DataReactor number to date in a cacheoff has been
2700 reqs/sec. That's about a factor of 20, and it had double the
price/performance of Swell's entry. The entry from Pyramid had
a performance about 10 times that of Swell, and a price/performance
about 5-6 times higher. So, if you want to model 10 caches versus 1,
it's also worth pointing out that those 10 caches will cost
$25K versus $5k. From queuing theory, it's also very unlikely that
those 10 caches will get a total performance that's 10 times a
single cache.

> One point I am trying to make is that the central box is a box with
> heavy load on it, and thus it has trouble keeping the latency down.

That's contrary to what the benchmark shows:
at 2700 requests/sec, the iCache 2500 showed hit times of 21.5ms and 2667ms,
both of which are faster than the Squid entry running at 130 reqs/sec.

It's true that for a particular instance, the hit/miss times will show
some increase as the load is increased. However, the argument as I
understood it was using a faster centralized cache versus slower
distributed caches.

-Vivek
Received on Sun Dec 23 2001 - 07:36:13 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:28 MST