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: Tue, 25 Dec 2001 09:08:07 -0500

Jon Kay wrote:
>
> Vivek starchily noted:
> > 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.
>
> You telling me that NONE of your OEMs have ever shaded anything?

To the best of my knowledge, all of our OEMs have offered the boxes
at the cacheoff at the time specified in the cacheoff rules. In
contrast, the "reiser-raw" Squid configuration from last year (which
achieved better numbers than the base Squid entry) was never stable,
and never available for sale. That's more than "shaded".

> Ahem. *Performance* has multiple components. Most of my assertions
> are about latency, which I regard as a more important bottom-line
> figure.

As I've said before, I see no reasons to believe numbers pulled out
of thin air for configurations that don't exist. There's no "bottom
line" figure for imaginary networks.

> > 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 is exactly what the benchmark shows. I was talking about the
> iMimic iMimic box. Man, you seem so unwilling to talk about that box :->.

I've stated before that if you insist on taking the best Squid numbers,
it makes sense to take the best DataReactor numbers. But, even our
Linux box beat Squid on overall time - 1.49 seconds versus 1.64 seconds.
So, if you want me to talk about it, versus Swell, it's got over 8 times
the performance, more than twice the price/performance, better overall
response time, higher hit rate, and higher bandwidth savings. Again,
not a shabby result, and that's the most favorable comparison. Our
OEM entries all rated even better in comparison.

> We could talk about the iCache 2500, seems like a nice box in many
> respects, but it is more expensive than your own iMimic box. An
> organization needs to have alot more users before they'll be looking
> for an iCache 2500.

If these were your criteria, you could have picked the Pyramid,
TNCLabs, or StrataCache F-120 entries. All have higher throughputs,
lower prices, and better hit/miss times than our Linux box.

I'm guessing the only reason you seem unwilling to consider our OEM
boxes is because your cooked comparison would fall apart then.
So, again, if you're going to reject the iCache based on price, you
should select one of the three boxes mentioned above since they're
all lower priced than the iMimic Linux entry.

> > 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.
>
> Well, yes, the *particular*instance* of a 10x load.
>
> In the cacheoff, we have a snapshot of Squid at load <k>, and
> the iMimic cache at load 10<k>. The cacheoff benchmark measured
> *sustained* performance. Exactly what we're looking for.

The iMimic box had a throughput 8.5 times that of Squid. The TNCLabs
box was much closer to 10 - 9.6, in fact. It had better hit times and
miss times than Squid, even though it was almost exactly 10 times the
performance.

-Vivek
Received on Tue Dec 25 2001 - 07:08:25 MST

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