> If you have a real point, please make it. Otherwise, if you're
> just throwing out random arguments to see which ones stick, I'll
> be more than happy to quote my consulting rates :-)
Lol!. I do agree with Jon's comment that a simple ping test (50 bytes or
thereabouts) doesn't adequately show the performance characteristics of
a network (unless 50 byte datagrams are what you are interested in) -
but I'd have said your ADSL (from memory) link is the one that would be
worth testing with a more appropriate test - say a TCP ping tool.
Other than that, this debate seems somewhat specious.
My 2c: Hint caching is a technique that will (IMO) improve any cache it
is applied to, as long as the overhead of hint lookups is <= the
decreased average retrieval time. Yes, this is circular logic (foo is a
technique that will improve any bar if it improves bar) :]. So in a less
circular fashion: Hint caching allows the trade of certain per request
latency and guesswork (ICP, hierarchy traversal) and network unaware
prediction (CARP) for local memory overhead and local lookups that allow
network aware forwarding. The Internet as a whole is not great and
indefinately scalable - *I'm writing this from Australia, where
bandwidth is still a premium expense for companies*. So _in certain
countries_ it's easy to see where the trade off will fall on the hint
caching side (for a reasonable implementation, and only compared to a
non-hint cache implementation of the same platform i.e. squid vs
squid+hint, or DataReactor vs DataReactor+hint). In other countries -
like I imagine the US - it's harder to see which side of the trade off
will be most economical without experimental evidence.
Given that background I see issues with comparing the DataReactor and
squid+hint.
1) It's an apple (squid+hint) and orange (DataReactor non-hint)
comparison.
2) I'm sure that iMimic can meet the Swell price point anytime they want
to. So the price comparison only make sense while iMimic are selling
monolithic caches, which AFAICT they will only stop doing when the
customer asks for something different - say many small hint caches.
3) If DataReactor can exceed the Swell price point (say the same price
at 3x performance) then a meaningful comparison might be made between a
squid+hint and a low end DataReactor, where the customer is choosing
between (n small+hint) and (n small @ 3x performance - per cache).
Nearly Last: Squid is sloooow. It's been acknowledged as slow for quite
some time. Don't flog a dead horse Jon. Why is it slow? Several reasons,
amongst them a lack of CPU scalability (single CPU only), highly
redundant code (how many times must a header be parsed?), and network
and disk io behaviour optimised for UNIX OS's 6+ years ago.
Tweaking of various parameters in squid may make a few percentage points
here and there, and is done for Cache off's etc, but until the core
issues (such as http client logic being performed in the http server
component, and disk IO being queued before client side data is pushed
through) squid simply won't get significantly faster.
Lastly: The main reason I love squid is it's huge flexability. It can do
NTLM/Basic/Digest authentication, ACL's on ip, DNS, regex, username,
external lookups, src and dest AS numbers, headers, small installs
(desktop cache peering via multicast on each workstation), moderately
big installs (smallish ISP core cache, or clustered caches in a bigger
environment), SSL accelerator, Web accelerator, HTTP request sanitiser,
HTTP bandwidth shaper (primitive but functional), CDN tool, WCCP (erggg
end-to-end violation erggg)
I've not seen any commercial cache that claims all that, delivers, and
gives me confidence in the quality of implementation. Maybe you do - but
as your on line documentation link is bust I cannot see for myself.
Rob
Received on Tue Dec 25 2001 - 07:59:28 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:29 MST